je suis intéressé par votre avis, je n’ai pas suffisamment de recul pour me faire une opinion, je trouve les venv rassurant pour ne pas faire de conneries
PDM
J’ai la même approche que pour flit, poetry, bento, pipenv, et companie :
- Ça coûte du temps pour apprendre les rouages de ce bouzin (à toi, et l’équipe à qui tu l’impose)
- Aucune garantie que ça soit encore maintenu dans 6 mois : il n’y a qu’un dev dessus, donc potentiellement il va falloir tout défaire (c’est pas comme si c’était pas déjà arrivé avec pipenv).
- Ça ne fait pas qu’une chose (comme la philosophie unix apprécie) mais plusieurs : il se place en remplacant de
pip(côté installation / gestion des dépendances / …) et du packaging (création de paquet). Les deux sont très corrélés : on y parle de gestion de dépendances.
D’un côté je trouve ça très bien que des gens expérimentent de nouvelles manière de faire, et surtout quand c’est une POC d’une PEP (la 0582 discutée ici), ça permet de tester une PEP avant de l’accepter, et parfois (souvent ?) de se rendre compte de petits détails qu’on aurait difficilement imaginé en exécutant le tout “dans notre tête”. Et le tester une fois sur un projet perso, j’ai rien contre.
De l’autre, je tiens ces expérimentations loin des projets sur lesquels je ne suis pas seul : pour les points cités plus haut : ça coûte du temps pour apprendre, puis parfois dé-apprendre, mais aussi pour des questions d’habitudes : arriver dans un nouveau projet et y retrouver ses habitues c’est une forme de confort. Quand a chaque projet auquel tu veux contribuer tu découvre une nouvelle manière d’installer, une nouvelle manière de packager, et que tu dois te retartiner la doc à chaque fois, ça décourage.
PEP 582
Je ne me suis pas encore fait un avis sur le sujet, mais l’activation et la désactivation des venv est un problème, et je suis content que les idées fusent pour essayer de le résoudre.
Personellement j’utilise une fonction bash pour gérer mes venvs:
venv ()
{
deactivate 2> /dev/null;
if ! [[ -d .venv ]]; then
python$1 -m venv --prompt "$(basename "$PWD"))(py$(python$1 --version | cut -d' ' -f2)" .venv;
fi;
source .venv/bin/activate
}
Ça fonctionne parce que j’ai plein de Python installés, ça me permet de créer/activer un venv pour la dernière version de Python en tapant juste venv, ou de préciser la version : venv 3.7 par exemple. Ça me nomme le venv du nom du dossier et de la version utilisée :
mdk@seraph:/tmp
$ mkdir pouette
mdk@seraph:/tmp
$ cd pouette
mdk@seraph:/tmp/pouette
$ venv
(pouette)(py3.9.0) mdk@seraph:/tmp/pouette
(notez que ça ne concerne que moi, ça n’impose rien aux contributeurs des projets sur lesquels j’utilise cette fonction, je l’utilise d’ailleurs pour contribuer à tous les projets auquels je contribue, de moi, ou pas).
mais si j’utilise une fonction c’est que ce qui est fourni ne me convient pas, c’est qu’il y a un problème à résoudre.
Pour revenir à la 582, niveau sécurité je n’aime pas trop le fait que cloner un repo, et exécuter Python dans le dossier du clone suffise déjà à exécuter du code du repo.
5 « J'aime »
J’utilise la même fonction que toi (merci beaucoup d’ailleurs), parce que j’aime cette notion de décalage entre les projets et l’indépendance par rapport à la machine elle-même.
De même, les nouveautés ont tendance à m’effrayer un peu au départ car on ne sait pas trop ce que ça va devenir et que ré-apprendre n’est pas toujours simple ni en terme de temps ni en terme de fun.
J’expérimente deux variantes en ce moment :
- Dans l’une j’installe mes prérequis à chaque venv : dotfiles/.bashrc at 58820cd89315843891c781a8e14787911b293e76 · JulienPalard/dotfiles · GitHub c’est une horreur, ça prend bien 20s, surtout depuis le nouvel algo de résolu de pip.
- Dans l’autre j’ai un “venv commun” à tous mes venvs, un peu comme si j’avais deux venvs d’activés. Je rajoute juste le /bin du venv commun à mon path, donc je ne peux pas y installer des libs, mais je peux y installer des exécutables.
Mais je pense que ces deux variantes vont trop loin, KISS comme on dit.
C’est marrant, parce que pendant un moment j’avais un venv par python (2 et 3) installé. Je me demande si je vais pas recommencer car j’utilise régulièrement les mêmes librairies, et donc ça me ferait gagner un temps précieux ainsi que de l’espace disque…
Quitte à avoir un venv spécifique de temps en temps… En fait je crois bien que je vais faire ça en repartant de ta fonction 
Bonjour,
J’ai un avis un peu plus simple sur le sujet.
Il existe des venv qui permettent une bonne isolation, pip est très pratique. On peut aussi créer nos propres modules réutilisables en utilisant pip sans avoir besoins de les télécharger. On peut aussi, très facilement les rendre public, un simple setup.py et __init__.py suffisent. On peut même les partager avec des liens symbolique (pip -e).
Si on désire une véritable isolation, on peut utiliser des systèmes de virtualisation légers comme docker ou k8s.
Le système proposé ici est beaucoup plus compliqué que l’utilisation de requirements.txt il me semble.
Je pense qu’un débutant s’est trouvé frustré et a pensé à réinventer la roue (intuition renforcée par l’exemple de visual studio), méfiance sur le moyen/long terme. Ce n’est pas un outil éprouvé.
Quelques astuces pour les utilisateurs de windows: 1. python se télécharge sur python.org pas sur le microsoft store ou via microsoft visual studio. 2. source .\venv\Scripts\activate permet d’activer le venv et python -m pip install virtualenv permet d’installer de quoi créer des venv.
A mon avis c’est là le vrai problème… et on ne peut pas le corriger en réinventant la roue :-).
Le risque ce n’est pas la nouveauté mais l’absence de nouveauté, des innovations uniquement sur versions majeures et des libraries standardisées imposées. Comme on le vois avec beaucoup de langages car justement on ne peut utiliser qu’une seule et unique version de celui-ci. C’est ce qu’apporte les venv justement, la possibilité d’utiliser une version X de python avec les libs dont tu as besoins, puis pour un autre projet de démarrer avec une nouvelle version avec les libs nécessaires. Pour moi l’argument “un débutant ne comprends pas les venv” est aussi stupide que de dire qu’un débutant ne fait pas la différence entre async et thread. Ce n’est pas parcequ’il y a un minimum de concepts à acquérir qu’il faut absolument créer une idiocratie. la PEP582 est pour moi un risque pour python, heureusement que je maitrise d’autres langages :D.
Après pour un projet j’ai aussi fait ça que je fait souvent, un simple makefile. GitHub - cgifl300-Studies-Projects/OC_P2: Projet 2 - OpenClassrooms
Pourquoi virtualenv (et pas venv ?)