Quelle est la différence entre venv, pyvenv, pyenv, virtualenv, virtualenvwrapper, pipenv, etc ?

Question

Python 3.3 inclut dans sa bibliothèque standard le nouveau paquetage venv . Que fait-il, et en quoi diffère-t-il de tous les autres paquets qui semblent correspondre à l'expression rationnelle ? (py)?(v|virtual|pip)?env ?

Answer 1

Recommandation pour les débutants :

Voici ma recommandation personnelle pour les débutants : commencez par apprendre virtualenv y pip Vous pouvez utiliser des outils qui fonctionnent à la fois avec Python 2 et 3 et dans diverses situations, et acquérir d'autres outils lorsque vous commencez à en avoir besoin.

Paquets PyPI ne faisant pas partie de la bibliothèque standard :

• virtualenv est un outil très populaire qui crée des environnements Python isolés pour les bibliothèques Python. Si vous ne connaissez pas cet outil, je vous recommande vivement de l'apprendre, car c'est un outil très utile, et je ferai des comparaisons avec lui pour le reste de cette réponse.

Il fonctionne en installant un ensemble de fichiers dans un répertoire (ex : env/ ), puis de modifier le PATH pour la faire précéder d'une variable d'environnement personnalisée bin (par exemple : env/bin/ ). Une copie exacte de la python o python3 est placé dans ce répertoire, mais Python est programmé pour rechercher d'abord les bibliothèques relatives à son chemin, dans le répertoire d'environnement. Il ne fait pas partie de la bibliothèque standard de Python, mais il est officiellement béni par la PyPA (Python Packaging Authority). Une fois activé, vous pouvez installer des paquets dans l'environnement virtuel en utilisant pip .

• pyenv est utilisé pour isoler les versions de Python. Par exemple, vous pouvez vouloir tester votre code contre Python 2.7, 3.6, 3.7 et 3.8, vous aurez donc besoin d'un moyen de passer de l'une à l'autre. Une fois activée, elle préfixe la balise PATH avec la variable d'environnement ~/.pyenv/shims où il y a des fichiers spéciaux correspondant aux commandes Python ( python , pip ). Il ne s'agit pas de copies des commandes livrées par Python ; ce sont des scripts spéciaux qui décident à la volée de la version de Python à exécuter en fonction de l'adresse de l'utilisateur. PYENV_VERSION ou la variable d'environnement .python-version ou le fichier ~/.pyenv/version fichier. pyenv facilite également le processus de téléchargement et d'installation de plusieurs versions de Python, en utilisant la commande pyenv install .

• pyenv-virtualenv est un plugin pour pyenv par le même auteur que pyenv pour vous permettre d'utiliser pyenv y virtualenv en même temps de manière pratique. Cependant, si vous utilisez Python 3.3 ou plus, pyenv-virtualenv essaiera d'exécuter python -m venv s'il est disponible, au lieu de virtualenv . Vous pouvez utiliser virtualenv y pyenv ensemble sans pyenv-virtualenv si vous ne voulez pas les fonctions de confort.

• virtualenvwrapper est un ensemble d'extensions de virtualenv (voir docs ). Il vous donne des commandes comme mkvirtualenv , lssitepackages et surtout workon pour basculer entre les différentes virtualenv les répertoires. Cet outil est particulièrement utile si vous souhaitez que plusieurs virtualenv les répertoires.

• pyenv-virtualenvwrapper est un plugin pour pyenv par le même auteur que pyenv pour intégrer commodément virtualenvwrapper en pyenv .

• pipenv vise à combiner Pipfile , pip y virtualenv en une seule commande sur la ligne de commande. Le site virtualenv est généralement placé dans ~/.local/share/virtualenvs/XXX avec XXX étant un hachage du chemin du répertoire du projet. Ceci est différent de virtualenv où le répertoire se trouve généralement dans le répertoire de travail actuel. pipenv est destiné à être utilisé lors du développement d'applications Python (par opposition aux bibliothèques). Il existe des alternatives à pipenv comme poetry que je ne vais pas énumérer ici puisque cette question ne concerne que les paquets qui portent un nom similaire.

Bibliothèque standard :

• pyvenv (à ne pas confondre avec pyenv dans la section précédente) est un script livré avec Python 3 mais déprécié dans Python 3.6 car il avait des problèmes (sans parler du nom qui prête à confusion). Dans Python 3.6+, l'équivalent exact est python3 -m venv .

• venv est un paquetage livré avec Python 3, que vous pouvez exécuter en utilisant python3 -m venv (bien que, pour une raison quelconque, certaines distros le séparent dans un paquetage distinct, comme par exemple python3-venv sur Ubuntu/Debian). Il sert le même objectif que virtualenv mais ne possède qu'un sous-ensemble de ses caractéristiques ( voir une comparaison ici ). virtualenv continue d'être plus populaire que venv d'autant plus que le premier supporte à la fois Python 2 et 3.

Answer 2

Je voudrais juste éviter l'utilisation de virtualenv après Python3.3+ et utiliser à la place la bibliothèque standard expédiée venv . Pour créer un nouvel environnement virtuel, vous devez taper :

$ python3 -m venv <MYVENV>  

virtualenv essaie de copier le binaire Python dans le répertoire bin de l'environnement virtuel. Cependant, il ne met pas à jour les liens vers les fichiers de bibliothèque intégrés dans ce binaire. Par conséquent, si vous compilez Python à partir des sources dans un répertoire non système avec des noms de chemin relatifs, le binaire Python se casse. Comme c'est ainsi que l'on fait une copie de Python distribuable, c'est un gros défaut. BTW pour inspecter les liens de fichiers de bibliothèque intégrés sous OS X, utilisez otool . Par exemple, à partir de votre environnement virtuel, tapez :

$ otool -L bin/python
python:
    @executable_path/../Python (compatibility version 3.4.0, current version 3.4.0)
    /usr/lib/libSystem.B.dylib (compatibility version 1.0.0, current version 1238.0.0)

Par conséquent, j'éviterais virtualenvwrapper y pipenv . pyvenv est déprécié. pyenv semble être utilisé souvent lorsque virtualenv est utilisé, mais je m'en tiendrais à l'écart également car je pense que venv fait aussi ce que pyenv est conçu pour.

venv crée des environnements virtuels dans le shell qui sont frais y bac à sable avec bibliothèques installées par l'utilisateur et c'est multi-python sûr .

Frais : parce que les environnements virtuels ne démarrent qu'avec les bibliothèques standard fournies avec python, vous devez réinstaller toutes les autres bibliothèques avec pip install pendant que l'environnement virtuel est actif.

Sandboxed L'installation de ces nouvelles bibliothèques n'est pas visible en dehors de l'environnement virtuel, vous pouvez donc supprimer l'environnement entier et recommencer sans vous soucier de l'impact sur votre installation de base de python.

Bibliothèques installées par l'utilisateur parce que le dossier cible de l'environnement virtuel est créé sans le nom de l'utilisateur. sudo dans un répertoire que vous possédez déjà, donc vous n'aurez pas besoin de sudo les autorisations pour y installer des bibliothèques.

multi-python sûr La raison en est que lorsque les environnements virtuels sont activés, le shell ne voit que la version de python (3.4, 3.5 etc.) qui a été utilisée pour construire cet environnement virtuel.

pyenv est similaire à venv en ce sens qu'il vous permet de gérer plusieurs environnements python. Cependant, avec pyenv vous ne pouvez pas commodément revenir à un état de départ pour les installations de bibliothèques et vous aurez probablement besoin de admin privilèges à un moment donné pour mettre à jour les bibliothèques. Je pense donc qu'il est également préférable d'utiliser venv .

Au cours des deux dernières années, j'ai constaté de nombreux problèmes dans les systèmes de construction (paquets emacs, créateurs d'applications autonomes python, installateurs...) qui, en fin de compte, se résument aux problèmes suivants virtualenv . Je pense que python sera une meilleure plateforme lorsque nous aurons éliminé cette option supplémentaire et que nous utiliserons seulement venv .

EDIT : Tweet de la BDFL,

J'utilise venv (dans la stdlib) et un tas d'alias shell pour changer rapidement.

- Guido van Rossum (@gvanrossum) 22 octobre 2020

Answer 3

MISE À JOUR 20200825 :

**Ajouté ci-dessous " Conclusion paragraphe "**

Je suis descendu dans la pipenv le terrier du lapin ( c'est un trou profond et sombre en effet... ) et puisque la dernière réponse remonte à plus de 2 ans J'ai pensé qu'il était utile de mettre à jour la discussion avec les derniers développements sur le sujet des enveloppes virtuelles Python que j'ai trouvés.

CLAUSE DE NON-RESPONSABILITÉ :

Cette réponse est PAS à propos de la poursuite du débat rageur sur les mérites des pipenv contre venv comme solutions d'enveloppe- Je ne cautionne ni l'un ni l'autre . Il s'agit de PyPA l'adoption de normes contradictoires et la façon dont le développement futur de la virtualenv promet de ne pas faire de ou bien pas du tout le choix entre les deux. Je me suis concentré sur ces deux outils précisément parce qu'ils ont reçu l'approbation de la Commission européenne. PyPA .

venv

Comme le note l'OP, venv est un outil de virtualisation des environnements. PAS une solution tierce, mais un outil natif. PyPA approuve venv pour créer ENVELOPPES VIRTUELLES : " Modifié dans la version 3.5 : L'utilisation de venv est maintenant recommandée pour créer des environnements virtuels. ".

pipenv

pipenv - comme venv - peut être utilisé pour créer des enveloppes virtuelles, mais il intègre en outre la gestion des paquets et la gestion de l'information. vérification de la vulnérabilité fonctionnalité. Au lieu d'utiliser requirements.txt , pipenv assure la gestion des paquets via Pipfile . Comme PyPA pour l'ene pour l'ene pour l ene GESTION DES PAQUETS ce qui semble impliquer pipfile est de supplanter requirements.txt .

CEPENDANT, : pipenv utilise virtualenv comme son outil de création d'enveloppes virtuelles, PAS venv qui est approuvé par PyPA comme l'outil de référence pour la création d'enveloppes virtuelles.

Normes contradictoires :

Comme si le choix d'une solution d'enveloppe virtuelle n'était pas déjà assez difficile, nous avons maintenant PyPA en soutenant deux outils différents qui utilisent des solutions d'enveloppe virtuelle différentes. Le débat qui fait rage sur Github concernant venv vs virtualenv qui met en évidence ce conflit peut être trouvé ici .

Résolution des conflits :

Le débat Github référencé dans le lien ci-dessus a orienté virtualenv développement dans le sens de l'adaptation venv en les versions futures :

préférer venv intégré : si le python cible possède venv, nous créerons l'environnement environnement en l'utilisant (et en effectuant des opérations ultérieures sur celui-ci pour faciliter les autres garanties que nous offrons)

Conclusion :

Il semble donc qu'il y aura une convergence future entre les deux solutions rivales d'enveloppe virtuelle, mais pour l'instant pipenv - qui utilise virtualenv - varie sensiblement de venv .

Étant donné que les problèmes pipenv résout le problème de et le fait que PyPA a donné sa bénédiction, il apparaît pour avoir un avenir brillant. Et si virtualenv en fonction des objectifs de développement proposés, le choix d'une solution d'enveloppe virtuelle ne devrait plus être une question de soit pipenv OU venv .

Mise à jour 20200825 :

Une critique souvent répétée de Pipenv J'ai constaté en produisant cette analyse qu'elle n'était pas activement maintenue. En effet, quel est l'intérêt d'utiliser une solution dont l'avenir peut être considéré comme douteux en raison de l'absence de développement continu ? Après un passage à vide d'environ 18 mois, Pipenv est à nouveau en cours de développement actif. En effet, des mises à jour importantes et matérielles ont depuis été libéré .

Answer 4

Commençons par les problèmes que ces outils veulent résoudre :

Le gestionnaire de paquets de mon système ne dispose pas des versions de Python que je souhaite ou je veux installer plusieurs versions de Python côte à côte, Python 3.9.0 et Python 3.9.1, Python 3.5.3, etc.

Ensuite, utilisez pyenv.

Je veux installer et exécuter plusieurs applications avec des dépendances différentes et conflictuelles.

Utilisez ensuite virtualenv ou venv. Ils sont presque totalement interchangeables, la différence étant que virtualenv prend en charge les anciennes versions de python et possède quelques autres fonctionnalités uniques mineures, tandis que venv fait partie de la bibliothèque standard.

Je développe une /application/ et j'ai besoin de gérer mes dépendances, et de gérer la résolution des dépendances de mon projet.

Ensuite, utilisez pipenv ou la poésie.

Je développe une /bibliothèque/ ou un /package/ et je veux spécifier les dépendances que les utilisateurs de ma bibliothèque doivent installer.

Utilisez ensuite setuptools.

J'ai utilisé virtualenv, mais je n'aime pas que les dossiers de virtualenv soient éparpillés dans divers dossiers de projets. Je veux une gestion centralisée des environnements et une gestion simple des projets.

Utilisez ensuite virtualenvwrapper. Variante : pyenv-virtualenvwrapper si vous utilisez également pyenv.

---

Non recommandé

• pyvenv. Ceci est déprécié, utilisez venv ou virtualenv à la place. A ne pas confondre avec pipenv ou pyenv.

Answer 5

Mise à jour de janvier 2020

@Flimm a très bien expliqué toutes les différences. En général, nous voulons connaître la différence entre tous les outils parce que nous voulons décider ce qui est le mieux pour nous. La question suivante est donc : lequel utiliser ? Je vous suggère de choisir l'un des deux moyens officiels de gérer les environnements virtuels :

• Python Packaging maintenant recommande Pipenv
• Python.org maintenant recommande venv