-
Notifications
You must be signed in to change notification settings - Fork 1
Description
Description
Pykhiops peut être installé de deux façons différentes, via conda ou via pip.
Ces installations sont testées extensivement, pour arriver à un fonctionnement correctement de pykhiops.
En revanche, comme l'utilisateur peut à tout moment lancer une action d'installation ou désinstallation de Khiops core ou de pykhiops, via pip ou conda, il faut également tester tous les états possibles issus des actions utilisateurs.
C'est important, car toutes ces actions sont "normales" dans de nombreux cas d'usage, quand on ne connait pas bien l'état en cours d'une machine: installation d'une nouvelle version, installation sur une machine, en n'ayant pas utilisé l'outil depuis longtemps, intervention sur la machine d'un collègue...
Tout ce qui peut arriver par un chemin quelconque d'installation arrivera, et il est moins cher de le tester a priori, que de fournir un support à posteriori en cas de problème, voire un patch des outils.
Questions/Ideas
On peut formaliser le problème des tests systématiques des chemins d'installation au moyen d'un diagramme états-transitions.
Il y a trois composant techniques:
- K: khiops core
- C: pykhiops via conda
- P: pykhiops via pip
et deux types d'action:
- i: installation
- u: desinstallation (uninstall)
Cela donne les états possibles d'une machine:
- états "happy":
- (): vide
- (K): Khiops core
- (C): pykhiops via conda
- (KP): pykhiops via pip, avec utilisation de Khiops core
- (KC): pykhiops via conda, plus Khiops core (usage "normal" via la librairie, et via la GUI)
- état "unhappy"
- (P): pykhiops via pip, sans son prérequis Khiops core
- (KPC): pykhiops a la fois via conda et via Khiops core
- (PC): pykhiops via conda, et via pip sans prérequis Khiops core
Les transitions possibles sont
- installation: iK, iC, iP
- désinstallation: uK, uC, uP
Globalement, on a donc huit états et six transitions, donc 48 changements d'états à tester, bien au delà des quelques tests du "happy" path.
On doit s'assurer que:
- quelque soit le chemin, on ne peut pas découvrir un nouvel état "cassé" au delà des huit états possibles
- quelque soit l'état, toute transition est possible
- cela ne sert à rien d'interdire une transition, car on peut arriver à un état par un autre chemin
- l'état final ne dépend pas de l'ordre des transitions
- quelque soit l'état, on a soit un état fonctionnel cohérent, soit un message d'erreur explicite, permettant à l'utilisateur de repasser à un état fonctionnel de façon autonome (sans support)
- pour les états mixant installation via pip et via conda: quand on lance python "naïvement" (par exemple via pycharm):
- peut-on forcer l'usage de pykhiops via conda ou pip?
- peut-on savoir s'il s'agit d'une installation via pip ou conda?
- peut-on savoir quelle est la version de Khiops utilisée (si versions distinctes de pykhiops conda et de Khiops core)?