Vous avez compris que Python sans virtualenv c’est comme la mer sans les vagues, c’est comme les vagues sans l’écume, c’est comme l’écume sans le sel, c’est comme le sel sans le poivre…
Mais c’est aussi appétissant que les méduses échouées.
Donc pour se faciliter la vie, vous utilisez virtualenvwrapper.
Et bien il y a plus meilleur : pew.
Non content d’avoir un nom cool et court, c’est un progrès non négligeable dans l’ergonomie de notre vie de dresseur de reptiles.
D’abord : pip install pew.
Ensuite, tableau d’équivalence avec virtualenvwrapper :
| virtualenvwrapper | pew | |
|---|---|---|
| Lister les env existant | workon | pew ls |
| Créer un env | mkvirtualenv name | pew new name |
| Supprimer un env | rmvirtualenv name | pew rm name |
| Activer un env | workon name | pew workon name |
| Aller dans le dossier site-packages | cdsitepackages | cd $(pew sitepackages_dir) |
| Valeur par défaut pour $WORKON_HOME (dossier qui contient tous les envs) | ~/.virtualenvs | ~/local/share/virtualenvs |
Vous noterez que les commandes de pew sont plus faciles à retenir, plus cohérentes, et toutes des sous-commandes histoire d’éviter de pourrir son espace de nom.
Autres avantages : pew n’a pas besoin qu’on ajoute un fichier à votre .bashrc pour marcher. Car pew ne source pas un env dans votre shell courant, il ouvre un nouveau shell. Pour sortir de l’env, c’est donc un simple Ctrl + D.
Seulement ça ne s’arrête pas là. Pew possède quelques commandes bonus qui changent bien la vie :
| virtualenvwrapper | pew | |
|---|---|---|
| Éxecuter la commande dans un env sans l’activer | Nope | pew in name commande |
| Éxecuter la commande dans tous les env | Non | pew inall commande |
| Dupliquer un virtualenv ailleurs | Nada | pew cp name destination |
| Ajouter un chemin au PYTHONPATH de l’env | Fuck it | pew add path |
| Changer la prise en compte des libs du site-packages du système quand on veut | I’m out | pew toggleglobalsitepackages |
| Créer un env temporaire supprimé dès qu’on en sort | Now you are just pushing it | pew mktmpenv |
| Choisir un dossier vers lequel aller à l’activation de l’env | BANG ! | pew setproject path |
Bon, le seul truc qui manque pour le moment, ce sont les hooks.
Sur le papier, c’est vraiment pas mal!
Néanmoins, sur la perf : ça lance un process python (et l’interpréteur python par conséquent) à chaque fois…
C’est du coup, c’est voué à être bcp plus lent que virtualenvwrapper (qui est déjà mou du genou quand on dépasse la centaine de projets sur du listing)
Je sais pas si on peut daemonizer pew pour qu’il soit réactif tout le temps?
J’avoues que je n’avais jamais encore recontré un mec qui avait des centaines d’env :)
Moi qui commence à faire joujou avec docker (grâce à vous, pour changer), est-ce qu’on ne peut pas remplacer virtualenv/pew par docker ? Ou est-ce que vous trouvez que les virtualenv gardent une valeur ajoutée par rapport à docker (mis à part le fait que ce soit pas forcément 100% utilisable sous windows, ca j’en sais rien) ?
Thanks !
Aller dans le dossier site-packages cdsitepackages cd $(pew sitepackages_dir)
Merci
Virtualenvwrapper a tout un paquet des commandes annoncées comme manquantes : mktmpenv, cdproject (si on bosse avec virtualenvwrapper en mode projets), allvirtualenv, add2virtualenv, cpvirtualenv, toggleglobalsitepackages… Regardez la doc un petit coup :p http://virtualenvwrapper.readthedocs.org/en/latest/command_ref.html
En effet, je l’ignorais. Je vais corriger l’article.
Pour passer de virtualenvwrapper à pew : http://hashbang.fr/de-virtualenvwrapper-a-pew.html
Une petite erreur dans la commande virtualenvwrapper pour “Lister les env existant”
c’est lsvirtualenv et non “workon”