Pipenv: Utilisez venv au lieu de virtualenv si disponible

je ne pense pas, je préfère utiliser personnellement la commande virtualenv

Peut-être est-il possible de faire coexister les deux options ? En parcourant négligemment la source, je ne vois rien de spécifiquement couplé à Virtualenv, à l'exception de la commande utilisée pour créer le fichier env. Virtualenv peut toujours être la valeur par défaut, mais l'utilisateur peut (par exemple) passer --venv pour créer .venv avec python3 -m venv au lieu de virtualenv .

Honnêtement, je m'appuierais uniquement sur pipenv et je me ficherais que virtualenv ou venv soit utilisé, mais j'ai pensé que nous pourrions tirer parti des fonctions intégrées lorsqu'elles sont disponibles.

J'exhorte @kennethreitz à reconsidérer son commentaire ici. L'utilisation de python3 -m venv au lieu de virtualenv est recommandée par la documentation standard. Personnellement, je suis rebuté par pipenv car il utilise virtualenv. Je n'utilise que Python 3 et n'utilise que venv de nos jours.

@bulletmark Maintenant que Pipenv délègue presque toute la gestion de Virtualenv à Pew, il est encore plus difficile de basculer, mais il est prévu que Pew prenne en charge venv (berdario/pew#67), donc il y a encore une chance. Si Pew peut le faire fonctionner, il serait beaucoup plus facile (et au moins plus logique pour moi) d'implémenter le support venv dans Pipenv.

@uranusjr sonne bien !

Personnellement, je n'ai jamais utilisé venv , d'où mon appréhension à son égard. Je suis sûr que c'est bon, cependant.

Les choses fonctionnent bien, en ce moment. Pas besoin de changer les choses qui ne sont pas cassées.

J'ai finalement trouvé ce fil parce que mon système est en panne.

Si vous créez un environnement avec virtualenv dans Python 3.X, puis mettez à niveau vers Python 3.Y, le virtualenv est cassé car vous savez que vous n'avez plus les bibliothèques partagées dont Python a besoin. En utilisant venv vous pouvez simplement exécuter python3 -m venv --upgrade .

Ce serait une fonctionnalité intéressante.

Ce serait certainement bien et se sent en ligne avec la direction de Python

Ne pas utiliser venv (et à la place utiliser virtualenv) est un obstacle total pour moi - je ne peux pas utiliser Pipenv. Je ne peux pas utiliser virtualenv en raison de son comportement frustrant de copie du binaire python et pourtant en fonction des bibliothèques partagées - comme dhouck l'a trouvé ci-dessus à son grand dam. Cela interrompt virtualenvs tout le temps (chaque fois que le système python est mis à jour, laissant le binaire en suspens) et copie inutilement le binaire python sans aucun avantage.

Si pipenv est l'avenir de Python, il devrait utiliser par défaut venv sur Python 3 (et avertir lorsqu'il ne l'utilise pas). Il est intégré à Python 3 et c'est l'outil recommandé. Il est très étrange que Pipenv soit également maintenant un outil recommandé, mais il n'utilise pas venv.

venv, par nature, faisant partie de Python lui-même, a accès aux composants internes de Python, ce qui signifie qu'il peut faire les choses correctement avec beaucoup moins de hacks. Par exemple, virtualenv doit copier le binaire de l'interpréteur Python dans l'environnement virtuel pour le tromper en lui faisant croire qu'il est isolé, tandis que venv peut simplement utiliser un fichier de configuration qui est lu par le binaire Python à son emplacement normal pour qu'il sache qu'il est censé agir comme si c'était dans un environnement virtuel. Ainsi, venv peut être considéré comme un virtualenv bien fait, avec la bénédiction et le soutien des développeurs Python.

Source : https://www.reddit.com/r/learnpython/comments/4hsudz/pyvenv_vs_virtualenv/

J'ai commencé berdario/pew#173, mais je n'ai pas eu beaucoup de temps pour progresser. Comme mentionné ci-dessus, Pipenv le prendra automatiquement en charge une fois que Pew le fera. J'aimerais avoir de l'aide si quelqu'un est intéressé à apporter venv à Pipenv. Le principal problème en ce moment serait de faire passer les tests.

Mise à jour rapide sur le support venv : cela n'arrivera pas, du moins dans un avenir proche. venv n'est tout simplement pas assez bon pour que cela se produise. Si vous vous souciez vraiment de cela, rendez-vous sur le suivi des bogues Python et donnez un coup de main. Sinon, tenez-vous-en à virtualenv .

venv est l'outil recommandé pour Python, et il n'est pas cassé, comme l'est virtualenv (re: copier le binaire python puis s'interrompt lors de la mise à jour des libs python). Le bogue auquel vous avez lié concerne la combinaison de venv et virtualenv, ce qui n'est pas ce que nous demandons ?

Malheureusement, il est extrêmement courant que les outils s'appuient sur virtualenv. Travis, par exemple, utilise virtualenv pour créer un environnement de construction pour vous, comme mentionné par le journaliste d'origine. C'est également la base de Pipsi, qui est l'un des moyens recommandés pour installer Pipenv. Si venv ne peut pas bien fonctionner à l'intérieur. C'est dans beaucoup d'endroits sans que vous le sachiez. Le support Venv serait à moitié cassé et vous mordrait de manière inattendue s'il ne pouvait pas bien fonctionner avec virtualenv.

Je comprends cela, mais à ce stade, Pipenv est recommandé, et venv est recommandé, et ils sont en quelque sorte en conflit. C'est un état très étrange.

Je suis tout à fait d'accord qu'il est dans un état étrange, c'est pourquoi j'essaie de le réparer :) Je ne dis pas que ce ne sera pas corrigé, mais il faut d'abord que des changements en amont se produisent, et je ne peux rien faire jusqu'à ce qu'ils se produire. Je publie le lien non pas comme une excuse pour arrêter de travailler dessus, mais pour faire savoir aux gens où mettre les efforts en premier pour aider à améliorer cette situation.

Ce ne serait peut-être pas trop fou de garder ce problème ouvert alors ?

C'est un problème de banc, pas un problème de pipenv.

venv n'est tout simplement pas assez bon pour que cela se produise. Si vous vous souciez vraiment de cela, rendez-vous sur le suivi des bogues Python et donnez un coup de main.

Ce n'est pas un problème de venv, mais de virtualenv. J'ai posté quelques explications sous le suivi des problèmes.
cc @uranusjr

Il y a un mot autour ->
Utilisez d'abord venv pour créer un virtualenv, puis exécutez pipenv install . Par example:

mkdir -p /tmp/try
cd /tmp/try
python3 -m venv .venv
pipenv --venv  # /tmp/try/.venv
pipenv install xxx

??

Juste une note:

La solution de contournement ci-dessus fonctionne principalement, mais pipenv run ... échoue pour moi car il n'y a pas de activate_this.py sous .venv/bin . Si l'on en croit le problème 21496 , il n'est pas prévu d'ajouter ce fichier à venv. Donc, même si pew résout ce problème, pipenv aurait probablement toujours un problème.

En utilisant virtualenv, l'utilisation du module tk du système dans macOS est impossible. Mais en utilisant venv, c'est possible.
Je souhaite fortement utiliser venv avec pipenv (peut-être en option).

Voir aussi : #1416

Je ne veux pas avoir l'air cynique, mais je veux fortement que quelqu'un écrive réellement le code pour prendre en charge cela s'il s'en soucie vraiment autant. J'ai rencontré de nombreuses personnes disant qu'elles étaient "fortement" à ce sujet, mais pour autant que je sache, je suis le seul à faire quoi que ce soit. Et j'ai échoué. Ce n'est pas aussi simple que vous le pensez. Si vous pensez que vous pouvez faire mieux, faites quelque chose. Si vous ne voulez pas, veuillez prendre ce que vous pouvez obtenir.

(Kenneth et moi-même et probablement Erin et Nate ont également essayé de le faire avec venv beaucoup plus tôt dans le projet et ont également échoué pour des raisons de compatibilité)

Ce serait bien, tout le monde est d'accord. J'aimerais le voir fonctionner sur toutes les plates-formes et versions python.

Je voudrais souligner une autre raison pour laquelle venv serait probablement un meilleur choix que virtualenv :

l'un des aspects les plus laids de l'implémentation de virtualenv est qu'il doit avoir sa propre copie du module de site, qui est utilisé pour tous les virtualenvs, quelle que soit la version de Python avec laquelle ils sont créés.
-- de https://github.com/pypa/virtualenv/issues/228#issuecomment -4165148

Cela signifie, par exemple, que rlcompleter est désactivé par défaut et c'est à mon avis une énorme perte de convivialité.

De plus, comme il s'agit d'un problème qui affecte plusieurs de vos utilisateurs, je suggérerais de le garder ouvert jusqu'à ce que le problème soit résolu, même si vous attendez que des changements se produisent en amont.

Encore. Nous savons que ce serait mieux. Ce n'est pas possible en fait. Selon vous, qu'est-ce qui a un impact plus négatif, interrompant complètement les fonctionnalités pour un large segment d'utilisateurs, ou obligeant certains utilisateurs à activer les fonctionnalités de lecture ?

Je suis sûr que c'est gênant, c'est aussi gênant qu'il semble y avoir seulement des gens qui demandent cela et pourtant personne qui offrira une implémentation qui fonctionne. Nous avons essayé. Jusqu'à ce que quelque chose change radicalement, nous n'avons pas l'intention de prendre en charge venv et donc pas l'intention d'ouvrir ce problème.

@techalchemy Si je comprends bien, pypa/virtualenv#1095 est le bon endroit pour en discuter ?

Cela semble juste, j'ai vu que tox avait une solution de contournement, alors peut-être que cela fonctionnerait si quelqu'un le portait

banc! quelle discussion .. si cette chose n'est pas si cruciale, serait-il possible de les supprimer complètement avec virtualenv et de laisser pipenv, venv et python aller de pair, car ils se recommandent tous les uns les autres?

Les solutions de gestion des dépendances/environnement virtuel pour python sont un terrain trop sauvage en ce moment, et certains sacrifices doivent être faits, à mon humble avis.

Cela pourrait effrayer de nombreuses personnes qui ne sont pas encore prêtes à arrêter d'utiliser virtualenv, mais cela pourrait être prévu pour l'une des prochaines versions majeures (si cela est techniquement faisable). Le changement est inévitable, ce n'est qu'une question de temps.

@doganmeh Nous pouvons abandonner complètement virtualenv, en créant un produit équivalent pour ne prendre en charge que Python 3.3 ou supérieur, mais je suppose qu'il serait plus facile d'en faire un autre projet.

Juste une note:

La solution de contournement ci-dessus fonctionne principalement, mais pipenv run ... échoue pour moi car il n'y a pas de activate_this.py sous .venv/bin . Si l'on en croit le problème 21496 , il n'est pas prévu d'ajouter ce fichier à venv. Donc, même si pew résout ce problème, pipenv aurait probablement toujours un problème.

Est-ce vraiment nécessaire? Une fois que vous avez créé un environnement virtuel avec venv, vous n'avez pas besoin de l'activer pour l'utiliser. Vous exécutez simplement en utilisant le binaire python du répertoire venv/bin.

FWIW, c'est lié (et ce qui m'a amené ici): http://matplotlib.org/faq/osx_framework.html

Dans un virtualenv , une version non-framework est utilisée même lorsque l'environnement est créé à partir d'une version framework ( virtualenv bug #54 , virtualenv bug #609 ).

La solution consiste à ne pas utiliser virtualenv, mais à la place le venv de stdlib , qui fournit des fonctionnalités similaires mais sans présenter ce problème.

L'abandon du support Python 2.7/virtualenv ne me semble pas être une idée particulièrement terrible, si cela permet à pipenv de s'appuyer sur la stdlib d'une version Python dont le support n'est pas sur le point d'expirer. Tant que cela ne corrompt aucune autre partie de la chaîne d'outils pipenv qui n'est pas facilement réparable pour les responsables. Peut-être même déplacer le support 2.7 vers une branche/un package séparé ?

J'aimerais pouvoir contribuer au code réel, mais je ne pense pas avoir l'expérience nécessaire pour le faire ou le temps :frown: Le mieux que je puisse faire est d'ajouter à la discussion pour le moment.

ajouter ma voix ici ; je viens de frapper ceci à cause du même problème que @dmtucker .

Je suis actuellement en train d'ignorer complètement pipenv pour ce projet sur mon mac et de créer l'environnement à la main avec venv pour le moment.

+1 pour utiliser venv.
virtualenv a de nombreux bugs wontfix .
pipenv complètement utile sur Windows 10 avec Python 3.7 du Windows Store (virtualenv bug#1362 )

virtualenv passe au modèle venv - voir https://github.com/pypa/virtualenv/issues/1366 , cela générera pyvenv.cfg et toutes les bonnes choses, donc cela devrait être résolu via cela.

---------- Message transféré ---------
De : Dan Ryan [email protected]
Date : lun. 26 nov. 2018, 14:39
Objet : Re : [pypa/pipenv] Utiliser venv au lieu de virtualenv si disponible (#15)
À : pypa/pipenv [email protected]
Cc: Souscrit [email protected]

Cela semble juste, j'ai vu que la toxine avait une solution de contournement, alors peut-être que cela fonctionnerait si
quelqu'un l'a porté

-
Vous recevez ceci parce que vous êtes abonné à ce fil.
Répondez directement à cet e-mail, consultez-le sur GitHub
https://github.com/pypa/pipenv/issues/15#issuecomment-441533872 , ou couper le son
le fil
https://github.com/notifications/unsubscribe-auth/AqyQvrs-RNNTb1YhxaDCWDLpRxrZLKoxks5uy4ydgaJpZM4Lqk2f
.