Salut @TiTidom,
En effet, je vais préciser un truc.
La fonction pyenv::createVirtualenv a un paramètre $_upgrade qui, quand il est mis à true, supprime et recrée le virtualenv, c’est vrai. Cette fonction sert à créer un virtualenv et si celui-ci existe, la fonction lance une exception. Donc pour recréer un virtualenv existant, il faut d’abord le supprimer.
D’un autre coté, il y a la fonction pyenv::runPyenv qui elle permet d’exécuter une commande dans le virtualenv passé en paramètre. Il est donc tout à fait possible de faire tout ce dont on a besoin de faire dans le virtualenv qu’on veut (pip y compris). La fonction pyenv::sourceScript retourne en texte, le script à lancer dans le virtualenv passé en paramètre. Libre à toi d’utiliser cette fonction et d’en modifier le retour.
Là, je ne te suis pas… C’est peut-être la différence entre un venv (terme que tu utilises) et un virtualenv (ce qui est utilisé dans p4J). Un virtualenv est un environnement isolé pour une version python donnée. Donc si tu veux upgrader la version python d’un virtualenv, il faut installer (et donc compiler) la nouvelle version de python, ce qui est de toute façon gourmand en ressources puis créer un virtualenv pour cette version de python.
Excellente remarque ! Il faudrait permettre de rediriger la sortie vers un autre fichier log.
Bonne idée !!
p4J a une page qui liste les virtualenv installés, c’est assez simple de trouver ses billes là-dedans.
Comme il n’y a pas d’équipements (utilisable) ni de commandes, la page de gestion est quasi vide et contient cette liste.
Avec la fonction pyenv::getVirtualenvNames, le plugin peut savoir si la version python nécessaire (et le virtualenv) est installée ou non et prévenir dans les logs que cette version doit être installée.
Dans post-install.sh, je fais un chown www-data:www-data -R ...
J’ai aussi eu des problèmes avec ça…
C’est la raison pour laquelle le nom d’un virtualenv créé par p4J contient en premier l’id du plugin. Par convention, ça veut dire que ce virtualenv est pour ce plugin. Pour un même plugin, il est même possible de créer plusieurs virtualenv avec la même version de python ou pas, il suffit de préciser un autre suffixe.
Je retiens l’idée de la redirection de log, pour le reste, il semblerait que p4J réponde à tous les points, sauf celui de l’emplacement du répertoire qui le contient. Il est cependant possible de faire un lien symbolique. Je vérifierai s’il est possible de modifier l’emplacement d’installation du virtualenv, mais a priori, ça ne me dit rien.
Comme les virtualenv sont de toute façon propres à un plugin (par convention) le fait que ce virtualenv soit stocker ailleurs que sous le répertoire du plugin ne pose pas de problème, sauf peut-être psychologique aux personnes possessives 
. Mais moi, je le vis bien 
Si p4J était intégré au core, je pense que le fonctionnement serait assez proche du fonctionnement actuel de p4J. Je m’avance peut-être…
Le « problème » de l’emplacement du virtualenv reste ouvert pour moi, mais je pense que la convention de nommage le résout sous forme de compromis à accepter s’il n’est pas possible de préciser où stocker le virtualenv.
Je remarque également qu’il faut plus d’explications sur le fonctionnement et les cas d’utilisation des fonctions de p4J. Mais est-ce que la doc sera lue ? Je ne peux que l’espérer étant donné le temps que ça prend. D’autant plus que cette doc est destinée aux devs qui pourraient avoir besoin de p4J, hors c’est eux (nous) les mieux placés pour savoir qu’une doc ça se lit !
Bien sûr j’essaie de te convaincre que p4J n’est pas si mal que ça au final et qu’il est forcément destiné à évoluer, puisqu’il n’a même pas un mois. Je ne veux pas que tu penses (ni que qui que ce soit le pense d’ailleurs) que c’est LA solution. Chaque dev est encore libre (et heureusement) de faire sa sauce dans son coin comme ça a été le cas jusqu’ici. p4J c’est juste une solution pour économiser des ressources chez les utilisateurs.
A+
Michel