Pipenv: Comment pipenv connaît-il le virtualenv du projet en cours ?

Le nom de virtualenv est le nom du répertoire racine du projet, plus le hachage du chemin complet vers la racine du projet. Cela garantit que le nom est unique et prévisible tant que vous ne déplacez pas le projet. (AFAICT cette logique de génération de nom est un détail d'implémentation sur lequel il ne faut pas se fier.)

Pour installer une version spécifique d'un package, utilisez la même syntaxe que vous le feriez avec pip et requirements.txt, par exemple pipenv install django==1.11.0 .

@uranusjr Cela signifie que si je renomme le répertoire, le virtualenv de mon projet sera perdu. C'est mauvais. Il peut être courant de renommer un répertoire et les utilisateurs peuvent tomber dedans et se demander comment leur environnement a cessé de fonctionner.

Je suggérerais de le réparer et de créer une entrée dans Pipfile si cela est possible. Ou créez un autre fichier .pipenv pour stocker ces métadonnées dans chaque répertoire de projet.

Que suggérez-vous ?

Merci d'avoir répondu aux deux questions !

Salut @sachinjain024 , nous avons eu quelques discussions sur le fichier de métadonnées local, mais le consensus du responsable a été que pipenv ne le supportera pas pour le moment.

Le chemin d'accès au répertoire identifiant un projet était quelque chose qui a été implémenté dès le début parce que les projets portant le même nom, ou plusieurs copies du même projet, provoquaient un écrasement accidentel de l'état de l'environnement.

Dans la pratique, nous avons constaté que beaucoup moins de personnes ont eu des problèmes avec l'emplacement faisant partie de l'environnement que de voir leur travail écrasé en silence. Pipenv est un outil de gestion de déploiement après tout, donc déplacer le répertoire devrait être un correctif d'une seule commande.

Merci @nateprewitt. Il est logique de passer rapidement à une mise en œuvre facile. Supposons que je renomme un projet à un stade ultérieur, cela signifie que mon environnement n'existe pas.

Alors que dois-je faire dans cette situation ?

1. Réinitialisez l'environnement car j'ai déjà Pipfile qui contient les informations sur les packages, il sera donc facile de réinitialiser le fichier env.
2. D'une manière ou d'une autre, renommez également le répertoire virtualenv
3. ???

Que proposez-vous dans ce cas ? Juste curieux au cas où je me retrouverais dans cette situation à l'avenir.

Vous pouvez utiliser pew cp pour copier facilement le virtualenv existant, mais 1. serait la façon la plus "canonique" de le faire, je pense.

@sachinjain024 , chaque fois que vous devez déplacer votre répertoire de projet, il vous suffit d'exécuter pipenv install pour revenir à un état de fonctionnement. Cela créera un environnement pour vous avec le nouveau hachage et réinstallera tout à partir du fichier de verrouillage de la même manière que l'installation précédente avec laquelle il a été créé.

Si vous vous retrouvez à le faire souvent, vous pouvez utiliser pew rm old_project-a3de90 pour nettoyer.

Je ne recommanderais pas d'utiliser pew cp moins que vous ne modifiiez l'environnement virtuel en dehors de pipenv. Dans ce cas, je pense que nous devrions considérer ce scénario comme une "garantie annulée", car il y a toutes sortes de changements que nous ne pouvons pas expliquer de manière fiable.

Merci @nateprewitt @uranusjr. Clôture de ce ticket.

C'est l'une des pires idées de pipenv jusqu'à présent. Voici pourquoi:

Je travaille dans une entreprise, où Python est utilisé pour l'automatisation des tests de nombreux projets internes. Un testeur travaille généralement sur une douzaine d'entre eux. Par convention, tout le code de test d'un projet réside dans un répertoire appelé tests . Cela signifie que chaque testeur a maintenant un tas d'environnements virtuels tous appelés quelque chose comme ~/.local/share/virtualenvs/tests-hKjFddnZ - génial ! C'est une nature humaine d'oublier de changer d'environnement virtuel, donc, tous les quelques jours, je suis appelé sur un poste de travail différent parce que la personne à ce poste de travail pense qu'elle a installé le package dont elle a besoin, elle a exécuté pipenv install , mais les importations dans le code ne fonctionnent pas. Non seulement cela, les environnements virtuels orphelins s'accumulent au fil du temps, mais comme tous ont des noms indescriptibles, il n'y a aucun moyen de savoir si je supprime l'environnement qui n'est pas utilisé ou celui qui a réellement été utilisé. Cela signifie qu'en CI, nous créons quotidiennement des dizaines, voire des centaines d'environnements virtuels. Il est impossible que quiconque puisse suivre les environnements qui ont des noms essentiellement aléatoires, et ils sont tout simplement trop nombreux, nous devons donc tous les supprimer au moins une fois par jour. Nous payons un lourd tribut en temps d'attente uniquement à cause de cette décision super intelligente prise par pipenv et quelqu'un dans notre entreprise, qui a décidé de l'utiliser...

Définissez export PIPENV_VENV_IN_PROJECT=1 dans votre configuration bashrc / shell.
(Ou modifiez vos scripts shell pour créer un venv à $PROJECT/.venv puis
pipenv aura ça)
Le lundi 19 mars 2018 à 6h28, wvxvw [email protected] a écrit :

C'est l'une des pires idées qui soit sortie de pipenv jusqu'à présent. Voici pourquoi:

Je travaille dans une entreprise, où Python est utilisé pour l'automatisation des tests de beaucoup de
projets internes. Un testeur travaille généralement sur une douzaine d'entre eux. Par
convention, tout le code de test d'un projet réside dans un répertoire appelé tests.
Cela signifie que chaque testeur dispose désormais d'un ensemble d'environnements virtuels tous
appelé quelque chose comme ~/.local/share/virtualenvs/tests-hKjFddnZ -
impressionnant! C'est dans la nature humaine d'oublier de changer d'environnement virtuel, donc,
tous les quelques jours, je suis appelé à un poste de travail différent parce que la personne
à ce poste de travail pense qu'ils ont installé le package dont ils ont besoin, ils
a exécuté pipenv install, mais les importations dans le code ne fonctionnent pas. Pas seulement
que, les environnements virtuels orphelins s'accumulent au fil du temps, mais puisque tous
d'entre eux ont des noms indescriptibles, il n'y a aucun moyen de savoir si je supprime
environnement qui n'est pas utilisé, ou celui qui a réellement été utilisé. Cette
signifie qu'en CI, nous créons des dizaines, voire des centaines d'environnements virtuels
du quotidien. Il est impossible que quiconque puisse suivre les environnements qui ont
essentiellement des noms aléatoires, et ils sont tout simplement trop nombreux, nous devons donc
supprimez-les tous au moins une fois par jour. Nous payons un lourd tribut en temps d'attente
seulement à cause de cette décision super intelligente prise par pipenv et quelqu'un dans
notre entreprise, qui a décidé de l'utiliser...

-
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/796#issuecomment-374211264 , ou couper le son
le fil
https://github.com/notifications/unsubscribe-auth/ABhjqyABdDHCB8WMm-hJwdkNptVlh8fuks5tf7KBgaJpZM4Pp3kf
.

@jtratner Alors pourquoi ai-je besoin de pipenv si je veux créer un environnement virtuel à la main ?

L'environnement virtuel est un travail en soi. Il est boiteux partout et est cassé sous Windows (il suppose que sous MS Windows, de tous les endroits, le répertoire de base par défaut s'appelle "~"). J'espérais que si quelqu'un devait refaire le PIP et l'environnement virtuel, il corrigerait, vous savez, les erreurs évidentes de leurs prédécesseurs... à la place, il y a ce gâchis multiplié par une couche d'incompatibilité.

Vous faites de fausses suppositions. Pipenv ne refait ni virtualenv ni pip. Il s'appuie sur eux.

@uranusjr c'est un problème de compréhension en lecture. Je sais très bien ce que fait pipenv , puisque je passe beaucoup plus de temps à déboguer son code que je ne le voudrais. Refaire l'environnement virtuel et le PIP est l'objectif affiché du projet. Cela, au lieu de les réparer, il a décidé de les utiliser "tels quels" est une autre énorme erreur de la part de pipenv , suivi de l'utilisation click bibliothèque

Refaire l'environnement virtuel et le PIP est l'objectif affiché du projet.

Où quelqu'un a-t-il déclaré cela?

J'ai également trouvé ce comportement étrange, je m'attendais pipenv ce que npm utilise node_modules .

@Flimm export PIPENV_VENV_IN_PROJECT=1 . Lisez la documentation.

@uranusjr J'ai lu tout https://docs.pipenv.org et https://docs.pipenv.org/basics/ , et à moins que je ne l' aie manqué, il ne mentionne jamais où les répertoires virtualenv sont installés, il n'avertit personne non plus que le fait de renommer ou de déplacer le répertoire du projet entraînera la recréation du répertoire virtualenv .

PIPENV_VENV_IN_PROJECT porte un nom confus, puisque pipenv n'utilise pas les venv fournis dans la bibliothèque standard, il utilise virtualenv , qui est un projet différent.

J'essaie juste de donner mon avis sur les choses sur lesquelles j'ai trébuché au fur et à mesure que je me familiarise avec ce projet.

@Flimm le but est d'abstraire cette information. Si vous savez comment fonctionnent les autres outils qui gèrent les virtualenvs, vous devez déjà savoir que le déplacement du dossier de virtualenvs les rend introuvables. Si vous n'êtes pas familier, vous n'irez probablement pas chercher cela en premier lieu.

En ce qui concerne la bibliothèque backend que nous utilisons pour générer des virtualenvs et la dénomination des variables d'environnement, la première n'est pas si importante et la seconde est un raccourci largement accepté. Bien que les détails soient importants, celui-ci ne donne pas l'impression de causer des problèmes à qui que ce soit, et votre principale objection semble basée sur le fait que vous ne savez pas quel backend nous utilisons pour mettre un exécutable python dans un dossier. Si vous rencontrez des bugs, veuillez les signaler. Nous n'allons vraiment pas changer les variables d'environnement _juste parce que_.

La variable d'environnement est facilement disponible dans la documentation : http://pipenv.readthedocs.io/en/latest/advanced/#configuration -with-environment-variables donc vous ne les avez probablement pas toutes lues si vous ne les avez pas vues ce

@techalchemy Par d'autres outils, je suppose que vous voulez dire quelque chose comme virtualenvwrapper . J'ai passé des années sans utiliser virtualenvwrapper . Je suppose que le nombre de développeurs Python qui connaissent le modèle node_modules de Node/NPM est supérieur au nombre de développeurs Python qui connaissent le virtualenvwrapper ou pipenv modèle de masquage du répertoire de l'environnement. Mais c'est une supposition. Pour ceux qui ne connaissent aucun de ces outils, je pense qu'il serait déroutant de ne pas savoir où se terminent les fichiers installés. Vous faites remarquer que cela n'est expliqué que dans la section avancée de la documentation sous la sous-section des variables d'environnement, je pense que cela devrait être expliqué dans la documentation beaucoup plus tôt que cela. Je vais peut-être soumettre une pull request.

J'ai commenté la référence confuse à venv au lieu de virtualenv dans la dénomination de PIPENV_VENV_IN_PROJECT dans un autre numéro #1919. Autant dire que je n'occupe pas tout à fait la position que je pense que vous pensez que j'occupe.

Dans tous les cas, la question dans le numéro d'origine est répondue. Je ne veux pas prolonger cette discussion, n'hésitez pas à avoir le dernier mot si vous le souhaitez.

Je comprends que ce n'est pas le bon public, mais puisque cette discussion est en cours... eh bien, je ne pense pas que node_modules été une inspiration pour pipenv , et pas pour virtualenv soit. Ma supposition est peut-être historiquement incorrecte, mais devoir travailler à la fois avec rbenv et virtualenv , je peux vous dire que virtualenv ressemble soit à une mauvaise copie sans compréhension, soit peut-être un premier prototype, qui a été amélioré de rbenv . Dans les deux cas, virtualenv est une risée par rapport à rbenv , et voici pourquoi :

Il copie les packages pour chaque environnement. C'est stupide, lent et déroutant. C'est juste une mauvaise décision de conception, mais plus probablement juste un manque de décision : c'est juste arrivé comme ça parce que quelqu'un a écrit du code pour mettre ces paquets dans un répertoire arbitraire. En plus de cela, cela ne fonctionne pas vraiment sous Windows. Au point qu'il n'a jamais vraiment été testé sur Windows... Une chose ridicule à ce sujet est qu'il teste le système d'exploitation, et une fois qu'il découvre qu'il fonctionne sous Windows, il définit le répertoire de base sur ~ , ce défaut peut plus tard être remplacé par certaines variables d'environnement, mais si vous essayez réellement d'exécuter votre automatisation dans un environnement supervisé et propre... virtualenv n'installera tout simplement jamais les packages dans le même répertoire.

Alors... pipenv prétend être un outil pour les êtres humains, un peu comme requests ... Je suppose ? Donc, il devrait améliorer les efforts immatures déployés par ses prédécesseurs... ? Et pourtant, au lieu de jeter les déchets de virtualenv , il l'utilise tel quel. Le wrapper n'est différent du programme encapsulé que par le fait qu'il ne permet pas / rend plus difficile l'utilisation de certaines des fonctions du programme encapsulé...

Dans ma vie, j'ai vu beaucoup de tentatives d'automatisation, qui étaient nulles, mais vous les gars, vous visez les étoiles, vous mettez toutes ces évaluations imméritées sur votre site, avant même d'avoir mis des informations utiles. Mais vous ne respectez pas la promesse. En réalité, vous manipulez simplement l'opinion publique, sans faire de véritable travail. Et maintenant, les programmeurs qui doivent faire de l'automatisation doivent faire face à un autre mal, simplement parce que quelqu'un voulait obtenir plus de "j'aime" sur GitHub...

@wvxvw En effet, vous vous cinq (quatre, voir ci-dessous) ans, et ne peut donc jamais s'en inspirer. De plus, ce sont des choses fondamentalement différentes, n'atteignant qu'un objectif similaire à la fin. La chose que vous recherchez (outil de gestion d'exécution inspiré de rbenv) est pyenv.

En ce qui concerne également le virtualenv qui n'est pas à la hauteur des autres outils, savez-vous qu'il existe depuis dix (10) ans ? Les exigences de développement logiciel changent beaucoup, et les hypothèses qu'il a formulées sont progressivement devenues obsolètes, et personne ne s'est soucié d'intervenir pour le remplacer. Vous souciez-vous suffisamment d'intensifier?

Je comprends que tout le monde mérite une chance de parler, mais se joindre à une discussion sans une compréhension minimale du sujet et commencer à pointer du doigt tout de suite, c'est assez impoli pour les contributeurs de Pipenv, virtualenv et des systèmes d'emballage Python dans leur ensemble. S'il vous plaît ne faites pas cela.

Edit : j'ai creusé. La version initiale de virtualenv, 0.8, a été faite en 2007, tandis que celle de rbenv (0.1) était en 2011, donc ils sont séparés de quatre ans, pas de cinq.

@wvxvw Je ne t'ai vu que proposer des insultes. Ce genre d'attitude n'est pas vraiment le bienvenu ici. Veuillez consulter notre code de conduite avant de continuer à publier.

J'ai eu le même problème après avoir changé le chemin du projet et perdu le mappage virtualenv d'origine, puis j'ai lu ce fil. Tout d'abord, j'apprécie le travail de l'équipe pipenv. J'ai juste quelques opinions que j'aimerais partager sur cette discussion :

1. Le document devrait en effet souligner le mécanisme de mappage entre le chemin du projet et env, au moins avertir les utilisateurs que changing project path would cause unmapping the original env .

2. Sera-ce mieux si vous pouvez définir manuellement le chemin d'accès à l'environnement dans le Pipfile ? Je veux dire que les gens peuvent avoir des exigences particulières pour utiliser manuellement le même env.

Juste mes opinions à partager avec vous les gars.

On ne sait pas du tout comment utiliser pipenv. Dois-je avoir plusieurs environnements virtuels pour un projet ? Dois-je partager les environnements virtuels entre les projets ? Comment installer une version différente de python pour un projet spécifique avec pipenv, si la version de python n'est nécessaire que pour ce projet ? Tout le monde est tellement imbu d'eux-mêmes dans ce fil, supposant un tas de choses sur les autres, n'essayant jamais de comprendre d'où viennent les autres. Quand j'ai lu les éloges de pipenv sur la page d'accueil, j'ai pensé que cela m'aiderait. Au lieu de cela, j'ai perdu 5 jours à lutter avec, et maintenant je pense que je retourne à Pyenv parce que c'était au moins quelque peu déterministe.

si vous souhaitez utiliser plusieurs environnements pour un projet, utilisez tox. Utilisez pipenv pour votre environnement de développement principal et tox pour tester plusieurs versions de python.

@ashnur tu as clairement besoin de quelque chose à faire. Au lieu de répandre la négativité parmi un projet open source géré par des bénévoles, pourquoi n'essayez-vous pas de contribuer quelque chose d'utile ?

@uranusjr
c'est là que le hachage se produit?

Je travaille sur un projet et j'ai besoin de calculer le hachage d'un chemin.

@devxpy Oui , exactement.

Je pense que vous devriez mettre un tutoriel de base sur la façon de configurer un virtualenv avec pipenv quelque chose de très basique parce que plus c'est facile pour les gens, plus les gens l'utiliseront, mais si cela crée de la confusion, alors plus de gens ne l'utiliseront peut-être pas et en chercheront d'autres langages ou méthodes pour y construire des projets

@uranusjr quelle est la raison pour laquelle Pipenv ne crée pas le virtualenv par défaut dans le répertoire du projet ? À mon avis, cela résoudrait le problème des environnements orphelins lorsque le projet est renommé/déplacé/supprimé. En outre, ce serait moins déroutant pour les personnes qui (un peu à juste titre) s'attendent à ce que cela fonctionne comme npm.

Y a-t-il un avantage à préférer cette approche en dehors peut-être de la tradition ?

Créez simplement le répertoire .venv avant la commande d'installation pipenv. Une option —venv ou —dot-venv pour installer pipenv serait la bienvenue, en fait :)

À partir de 2018.10.9, il existe une autre façon de procéder. Vous pouvez ajouter un fichier .venv contenant le chemin d'accès à votre environnement virtuel. (Nouvelle fonctionnalité sournoise !)

@andrewpeterprifer Parce que nous avions l'habitude de faire cela et que nous devions le changer car certaines personnes ont rejeté très fortement. Nous devons choisir une approche ou une autre, et j'ai dû admettre qu'il est préférable de ne pas mettre d'environnements virtuels dans le répertoire du projet.

ps Seriez-vous (ou quelqu'un d'autre) intéressé à écrire une FAQ à ce sujet ? Cela prendrait probablement quelques paragraphes, mais je serais plus qu'heureux d'expliquer si quelqu'un promet de prendre le temps de peaufiner le texte et de soumettre un PR.

@uranusjr Je suis super curieux de savoir pourquoi c'est une meilleure valeur par défaut. Je suis relativement novice en python et maintenant j'ai l'impression qu'il me manque quelque chose d'évident concernant les meilleures pratiques. :) Merci!

PS. : Je pourrais écrire une FAQ si vous expliquez pourquoi les choses sont comme elles sont. ;)

À partir de 2018.10.9, il existe une autre façon de procéder. Vous pouvez ajouter un .venv _file_ contenant le chemin d'accès à votre environnement virtuel. (Nouvelle fonctionnalité sournoise !)

@andrewpeterprifer Parce que nous avions l'habitude de faire cela et que nous devions le changer car certaines personnes ont rejeté très fortement. Nous devons choisir une approche ou une autre, et j'ai dû admettre qu'il est préférable de ne pas mettre d'environnements virtuels dans le répertoire du projet.

ps Seriez-vous (ou quelqu'un d'autre) intéressé à écrire une FAQ à ce sujet ? Cela prendrait probablement quelques paragraphes, mais je serais plus qu'heureux d'expliquer si quelqu'un promet de prendre le temps de peaufiner le texte et de soumettre un PR.

Je suis désolé de rentrer... J'ai le même besoin de déplacer des dossiers de projets qui ont un environnement virtuel créé avec pipenv.

Actuellement, je fais ce qui suit et n'ai aucun problème du tout:

• Je déplace le dossier du projet où je veux
• dans C:\Users\user\.virtualenvs je supprime le dossier du venv associé au projet que je viens de déplacer
• Je navigue vers le nouvel emplacement du dossier de projet via cmd et j'exécute pipenv install (ou pipenv shell puis pipenv sync)

Tout fonctionne bien. Est-ce une mauvaise pratique ?

Concernant le commentaire @uranusjr, si je comprends bien avec la nouvelle fonctionnalité, je devrais ajouter le fichier .venv (contenant le chemin d'accès à l'environnement virtuel souhaité) dans le dossier du projet, n'est-ce pas ? Et cela m'éviterait d'avoir à faire toutes les démarches que j'ai évoquées précédemment ? Si c'est le cas c'est super !!
Si tel est le cas, ne serait-il pas préférable qu'un tel fichier soit automatiquement créé dans le dossier du projet lors de la création initiale de l'environnement virtuel ?

PS: je suis également prêt à écrire une FAQ

En fait, je pense que l'idée de @gioxc88 est bonne, un virtualenv nouvellement créé peut générer automatiquement un fichier .env sous la racine du projet et contient des configurations env comme PATH . Cela rendra l'environnement plus transparent pour les développeurs et un moyen plus pratique de reconfigurer.

Je vais essayer de répondre à vos questions ensemble. L'approche n'est pas mauvaise (IMO, j'utilise moi-même la même configuration). Il est cependant plus facile pour un utilisateur inconscient de trébucher.

Une façon d'y penser serait d'envisager de mettre un projet en contrôle de version (disons Git). Si l'environnement est créé à la racine du projet, il sera naturellement à la racine du référentiel. Les gens comme vous et moi, qui sommes habitués à cette configuration, savent évidemment que nous devrions ajouter une règle dans .gitignore (ou la configuration globale d'ignorance) pour empêcher l'enregistrement du répertoire .venv , mais un utilisateur sans méfiance ne le ferait pas et pourrait très facilement vérifier dans l'environnement par accident. Ce n'est pas seulement mauvais pour la gestion de projet, mais (plus important encore) fournit un vecteur d'attaques potentielles en exposant des informations locales. Par conséquent, c'est une règle générale pour les outils de gestion de projet d' éviter de placer les fichiers générés dans le répertoire du projet . Cela pourrait être acceptable (toujours pas optimal pour l'OMI) de le faire si vous concevez un écosystème à partir de zéro (par exemple, le node_modules NPM), mais ce n'est certainement pas une bonne idée pour les outils conçus pour un écosystème avec des pratiques communes établies, comme dans le cas de Pipenv.

Si un environnement est généré par défaut en dehors de la racine du projet, il y a une chose de moins à craindre lorsque vous publiez votre projet (par exemple, le pousser vers GitHub). Cela rend notre vie (qui préfèrent les environnements dans le projet) un peu plus difficile, mais du point de vue du risque, le pire qui puisse arriver est de déplacer accidentellement le projet et de casser l'environnement, ou d'oublier de supprimer un environnement lorsqu'un projet est supprimé . L'un ou l'autre est beaucoup, beaucoup plus facilement récupérable que de transmettre accidentellement vos informations d'environnement potentiellement sensibles à GitHub.

La fonctionnalité de fichier .venv est encore assez récente (sortie il y a quelques jours seulement) et nous explorons toujours les moyens de l'utiliser au mieux. Il a toujours le même problème d'un répertoire .venv , mais j'espère que ce n'est pas aussi grave. J'aime beaucoup cette fonctionnalité moi-même et j'espère vraiment que nous pourrons l'utiliser pour améliorer l'expérience utilisateur, mais il y a encore beaucoup à considérer ici.

Salut. Pour moi, le répertoire .venv (ancienne fonctionnalité) et le fichier .venv (nouvelle fonctionnalité) sont ok, mais je serais très reconnaissant d'avoir une option dans la commande d'installation pipenv.

Quelque chose comme:

pipenv install

S'installerait dans ~/.local/

pipenv install --venv

S'installerait dans le répertoire $PWD/.venv

pipenv install --venv-dir /my/custom-path

S'installerait dans /my/custom-path .

Si vous souhaitez une nouvelle fonctionnalité, merci de bien la proposer en faisant une proposition d'amélioration à ~/.peeps . Veuillez ne pas faire de propositions d'amélioration dispersées au hasard autour de divers problèmes, ce n'est pas traçable.

@uranusjr merci pour la réponse détaillée ! Juste pour satisfaire ma curiosité, quel type d'informations locales (potentiellement sensibles) pourrait être exposé par un python venv vérifié? Je suis d'accord que c'est ennuyeux si node_modules est archivé, mais normalement cela ne contiendrait aucune information locale.

Les environnements virtuels Python contiennent plusieurs scripts shell (par exemple activate ). Beaucoup de gens les modifient pour ajouter des variables d'environnement pour spécifier les mots de passe de la base de données, le chemin vers un autre fichier de configuration, etc. La modification des scripts dans les environnements virtuels est contraire aux meilleures pratiques, mais les gens le font néanmoins (et se mettent sur la défensive lorsque vous leur dites d'arrêter de le faire -expérience personnelle).

De plus, vous avez raison, node_modules ne contient probablement pas d'informations sensibles. C'est un autre avantage lorsque vous construisez un écosystème à partir de zéro. Les environnements virtuels Python ont malheureusement été inventés bien avant que cela ne soit un problème courant (à l'époque, vous êtes déjà un gourou si vous utilisez VCS).

Je suis arrivé ici alors que j'essayais de comprendre comment pipenv connaît le bon virtualenv : )

Merci les gars pour cette discussion. Probablement, cela pourrait être une bonne idée de spécifier dans la page principale (par exemple, ici ) que renommer le chemin du projet casse le mécanisme par défaut de la liaison virtualenv.

Toutes les pages de documentation sont ouvertes à la contribution. Ne demande rien, fais-le :)

Je vais!

@uranusjr Cela signifie que si je renomme le répertoire, le virtualenv de mon projet sera perdu. C'est mauvais. Il peut être courant de renommer un répertoire et les utilisateurs peuvent tomber dedans et se demander comment leur environnement a cessé de fonctionner.

Je suggérerais de le réparer et de créer une entrée dans Pipfile si cela est possible. Ou créez un autre fichier .pipenv pour stocker ces métadonnées dans chaque répertoire de projet.

Que suggérez-vous ?

Merci d'avoir répondu aux deux questions !

merci d'avoir posé la question à tous les deux. je rencontre aussi le même problème,

Si vous avez initialisé pipenv dans un mauvais répertoire et devez utiliser le répertoire virtualenv du bon répertoire, vous pouvez obtenir le chemin virtualenv en faisant pipenv --venv et déplacer les PIpfile et Pipfile.lock dans le bon répertoire.

echo ${PATH_OBTAINED_FROM_PREVIOUS_COMMAND} > .venv dans le bon répertoire et cela devrait fonctionner correctement.

J'ai remarqué aujourd'hui que s'il y a un pipfile dans le répertoire parent, pipenv ignore la variable d'environnement export PIPENV_VENV_IN_PROJECT=1 et installe un venv dans le répertoire parent à la place. C'est sur la version 2018.11.26 . Si vous supprimez le fichier pip du répertoire parent, pipenv fonctionne comme indiqué.