Pipenv: Woher kennt pipenv die virtualenv für das aktuelle Projekt?

Der Name von virtualenv ist der Stammverzeichnisname des Projekts plus dem Hash des vollständigen Pfads zum Projektstamm. Dies garantiert, dass der Name eindeutig und vorhersehbar ist, solange Sie das Projekt nicht verschieben. (AFAICT diese Namensgenerierungslogik ist ein Implementierungsdetail, auf das man sich nicht verlassen sollte.)

Um eine bestimmte Version eines Pakets zu installieren, verwenden Sie dieselbe Syntax wie für pip und Requirements.txt, zB pipenv install django==1.11.0 .

@uranusjr Dies bedeutet, dass die virtualenv meines Projekts verloren geht, wenn ich das Verzeichnis umbenenne. Das ist schlecht. Es kann ein häufiger Anwendungsfall sein, ein Verzeichnis umzubenennen, und Benutzer können darauf hereinfallen und sich fragen, warum ihre Umgebung nicht mehr funktioniert.

Ich würde vorschlagen, es zu beheben und einen Eintrag in Pipfile vorzunehmen, wenn dies möglich ist. Oder erstellen Sie eine weitere .pipenv-Datei, um solche Metadaten in jedem Projektverzeichnis zu speichern.

Was schlagen Sie vor ?

Danke für die Beantwortung der beiden Fragen!

Hey @sachinjain024 , wir hatten einige Diskussionen über die lokale Metadatendatei, aber die Betreuer waren sich einig, dass pipenv dies derzeit nicht unterstützt.

Der Verzeichnispfad, der ein Projekt identifiziert, wurde schon früh implementiert, da Projekte mit demselben Namen oder mehreren Kopien desselben Projekts ein versehentliches Überschreiben des Umgebungsstatus verursachten.

In der Praxis haben wir festgestellt, dass weit weniger Menschen Probleme damit hatten, dass der Standort Teil der Umgebung ist, als dass ihre Arbeit stillschweigend überschrieben wurde. Pipenv ist schließlich ein Deployment-Management-Tool, daher sollte das Verschieben des Verzeichnisses mit einem Befehl behoben werden.

Danke @nateprewitt. Es ist sinnvoll, schnell zur einfachen Implementierung zu springen. Angenommen, ich benenne ein Projekt zu einem späteren Zeitpunkt um, dann bedeutet dies, dass meine Umgebung nicht existiert.

Was also soll ich in dieser Situation tun?

1. Setzen Sie die Umgebung zurück, da ich bereits Pipfile habe, das die Paketinformationen enthält, damit die Umgebung einfach zurückgesetzt werden kann.
2. Irgendwie auch das virtualenv-Verzeichnis umbenennen
3. ???

Was schlagen Sie in diesem Fall vor? Nur neugierig, falls ich in Zukunft in diese Situation komme.

Sie können pew cp um die vorhandene virtualenv einfach zu kopieren, aber 1. wäre meiner Meinung nach der "kanonischere" Weg, dies zu tun.

@sachinjain024 , wann immer Sie Ihr Projektverzeichnis verschieben müssen, sollten Sie nur pipenv install ausführen müssen, um in den Arbeitszustand zurückzukehren. Dadurch wird für Sie eine Umgebung mit dem neuen Hash erstellt und alles von der Lockfile identisch mit der vorherigen Installation, mit der sie erstellt wurde, neu installiert.

Wenn Sie dies häufig tun, können Sie pew rm old_project-a3de90 zum Aufräumen verwenden.

Ich würde nicht empfehlen, pew cp sei denn, Sie ändern die virtuelle Umgebung außerhalb von pipenv. In diesem Fall, denke ich, müssen wir dies als ein Szenario mit "ungültiger Garantie" betrachten, da es alle möglichen Änderungen gibt, die wir nicht zuverlässig erklären können.

Danke @nateprewitt @uranusjr. Schließe dieses Ticket.

Dies ist eine der schlechtesten Ideen, die bisher aus pipenv sind. Hier ist der Grund:

Ich arbeite in einem Unternehmen, in dem Python für die Testautomatisierung vieler interner Projekte verwendet wird. Ein Tester arbeitet normalerweise an einem Dutzend davon. Laut Konvention befindet sich der gesamte Testcode für ein Projekt in einem Verzeichnis namens tests . Das bedeutet, dass jeder Tester jetzt eine Reihe virtueller Umgebungen hat, die alle so etwas wie ~/.local/share/virtualenvs/tests-hKjFddnZ heißen - großartig! Es ist eine menschliche Natur zu vergessen virtuellen Umgebung zu wechseln, so alle paar Tage , die ich auf einer anderen Workstation genannt werde , weil die die Person an dieser Workstation denkt , dass sie das Paket installiert die sie benötigen, sie liefen pipenv install , aber die Importe im Code funktionieren nicht. Darüber hinaus sammeln sich die verwaisten virtuellen Umgebungen im Laufe der Zeit an, und da sie alle unscheinbare Namen haben, kann ich nicht feststellen, ob ich eine Umgebung lösche, die nicht verwendet wird oder die tatsächlich verwendet wird. Das bedeutet, dass wir in CI täglich Dutzende, wenn nicht sogar Hunderte von virtuellen Umgebungen erstellen. Es gibt keine Möglichkeit, Umgebungen zu verfolgen, die im Wesentlichen zufällige Namen haben, und es gibt einfach zu viele davon, also müssen wir alle mindestens einmal am Tag löschen. Wir zahlen einen enormen Tribut an Wartezeiten nur wegen dieser superintelligenten Entscheidung von pipenv und jemandem in unserer Firma, der sich entschieden hat, sie zu nutzen...

Setzen Sie export PIPENV_VENV_IN_PROJECT=1 in Ihrer Bashrc/Shell-Konfiguration.
(Oder ändern Sie Ihre Shell-Skripte, um ein venv unter $PROJECT/.venv zu erstellen und dann
pipenv wird das haben)
Am Mo, 19. März 2018 um 6:28 Uhr schrieb wvxvw [email protected] :

Dies ist eine der schlechtesten Ideen, die bisher aus pipenv hervorgegangen sind. Hier ist der Grund:

Ich arbeite in einem Unternehmen, in dem Python für die Testautomatisierung von vielen verwendet wird
interne Projekte. Ein Tester arbeitet normalerweise an einem Dutzend davon. Durch
Konvention befindet sich der gesamte Testcode für ein Projekt in einem Verzeichnis namens tests.
Dies bedeutet, dass jeder Tester jetzt über eine Reihe von virtuellen Umgebungen verfügt
so etwas wie ~/.local/share/virtualenvs/tests-hKjFddnZ genannt -
genial! Es liegt in der Natur des Menschen, zu vergessen, die virtuelle Umgebung zu wechseln.
alle paar tage werde ich an einen anderen arbeitsplatz gerufen weil die person
an dieser Workstation denkt, dass sie das benötigte Paket installiert haben, sie
habe pipenv install ausgeführt, aber die Importe im Code funktionieren nicht. Nicht nur
dass sich die verwaisten virtuellen Umgebungen im Laufe der Zeit anhäufen, aber da alle
von ihnen haben unscheinbare Namen, es gibt keine Möglichkeit zu sagen, ob ich lösche
Umgebung, die nicht verwendet wird oder die tatsächlich verwendet wird. Dies
bedeutet, dass wir in CI Dutzende, wenn nicht Hunderte von virtuellen Umgebungen erstellen
Täglich. Es gibt keine Möglichkeit, Umgebungen zu verfolgen, die
im Wesentlichen zufällige Namen, und es gibt einfach zu viele davon, also müssen wir
lösche sie alle mindestens einmal am Tag. Wir zahlen eine riesige Maut in Wartezeiten
nur wegen dieser superintelligenten entscheidung von pipenv und jemandem in
unser Unternehmen, das sich entschieden hat, es zu verwenden ...

—
Sie erhalten dies, weil Sie diesen Thread abonniert haben.
Antworten Sie direkt auf diese E-Mail und zeigen Sie sie auf GitHub an
https://github.com/pypa/pipenv/issues/796#issuecomment-374211264 oder stumm
der Faden
https://github.com/notifications/unsubscribe-auth/ABhjqyABdDHCB8WMm-hJwdkNptVlh8fuks5tf7KBgaJpZM4Pp3kf
.

@jtratner Warum brauche ich dann pipenv wenn ich eine virtuelle Umgebung von Hand erstellen möchte?

Die virtuelle Umgebung ist ein Stück Arbeit für sich. Es ist überall lahm und unter Windows kaputt (es geht davon aus, dass ausgerechnet unter MS Windows das Standard-Home-Verzeichnis "~" heißt). Ich hatte gehofft, dass, wenn jemand PIP und virtuelle Umgebung wiederherstellen würde, er die offensichtlichen Fehler seiner Vorgänger beheben würde ... stattdessen gibt es dieses Durcheinander, multipliziert mit einer Ebene der Inkompatibilität.

Sie machen falsche Annahmen. Pipenv wiederholt weder virtualenv noch pip. Auf ihnen baut es auf.

@uranusjr das ist ein Leseverständnisproblem. Ich weiß sehr gut, was pipenv macht, da ich viel mehr Zeit damit verbringe, seinen Code zu debuggen, als mir lieb ist. Die Wiederherstellung der virtuellen Umgebung und des PIP ist das erklärte Ziel des Projekts. Dass, anstatt sie zu reparieren, beschlossen wurde, sie "wie sie sind" zu verwenden, ist ein weiterer großer Fehler von pipenv , gefolgt von der Verwendung der click Bibliothek, und die Liste geht weiter.

Die Wiederherstellung der virtuellen Umgebung und des PIP ist das erklärte Ziel des Projekts.

Wo hat das jemand behauptet?

Ich fand dieses Verhalten auch seltsam, ich hatte erwartet, dass pipenv einen Standardnamen für ein virtualenv-Verzeichnis wählt und das Verzeichnis im aktuellen Verzeichnis ablegt, ähnlich wie npm node_modules .

@Flimm export PIPENV_VENV_IN_PROJECT=1 . Lesen Sie die Dokumentation.

@uranusjr Ich habe alle https://docs.pipenv.org und https://docs.pipenv.org/basics/ gelesen, und wenn ich es nicht übersehen habe, wird nie erwähnt, wo die Verzeichnisse virtualenv installiert sind. Es warnt auch niemanden, dass das Umbenennen oder Verschieben des Projektverzeichnisses dazu führt, dass das Verzeichnis virtualenv neu erstellt werden muss.

PIPENV_VENV_IN_PROJECT ist verwirrend benannt, da pipenv nicht venv , das in der Standardbibliothek enthalten ist, sondern virtualenv , was ein anderes Projekt ist.

Ich versuche nur, Feedback zu den Dingen zu geben, über die ich gestolpert bin, während ich mich mit diesem Projekt vertraut mache.

@Flimm es geht darum, diese Informationen zu abstrahieren. Wenn Sie wissen, wie andere Tools zum Verwalten von Virtualenvs funktionieren, sollten Sie bereits wissen, dass das Verschieben von Ordnern von Virtualenvs sie unauffindbar macht. Wenn Sie nicht vertraut sind, werden Sie wahrscheinlich gar nicht erst danach suchen.

Was die Backend-Bibliothek angeht, die wir zum Generieren von virtuellen Umgebungen und die Benennung von Umgebungsvariablen verwenden, ist ersteres nicht so wichtig und letzteres ist eine allgemein akzeptierte Kurzform. Obwohl Details wichtig sind, hat diese hier nicht das Gefühl, dass sie irgendjemandem Probleme bereitet, und Ihr Haupteinwand scheint darauf zu beruhen, dass Sie sich nicht sicher sind, welches Backend wir verwenden, um eine ausführbare Python-Datei in einem Ordner abzulegen. Wenn Sie auf Fehler stoßen, melden Sie diese bitte. Wir werden die Umgebungsvariablen wirklich nicht ändern, _nur weil_.

Die Umgebungsvariable ist in den Dokumenten leicht verfügbar: http://pipenv.readthedocs.io/en/latest/advanced/#configuration -with-environment-variables, also haben Sie wahrscheinlich nicht alle gelesen, wenn Sie sie nicht gesehen haben es

@techalchemy Mit anderen Tools meinst du wohl so etwas wie virtualenvwrapper . Ich habe jahrelang ohne virtualenvwrapper . Ich vermute, dass die Zahl der Python-Entwickler, die mit dem node_modules Muster von Node/NPM vertraut sind, größer ist als die Zahl der Python-Entwickler, die mit den virtualenvwrapper oder pipenv vertraut sind

Ich habe die verwirrende Bezugnahme auf venv anstelle von virtualenv in der Benennung von PIPENV_VENV_IN_PROJECT in einer anderen Ausgabe #1919 kommentiert. Es genügt zu sagen, dass ich nicht ganz die Position halte, von der Sie denken, dass ich sie vertrete.

In jedem Fall ist die Frage in der Originalausgabe beantwortet. Ich möchte diese Diskussion nicht in die Länge ziehen, Sie können gerne das letzte Wort haben, wenn Sie es wollen.

Ich verstehe, dass dies das falsche Publikum ist, aber da diese Diskussion im Gange ist... nun, ich glaube nicht, dass node_modules eine Inspiration für pipenv waren und nicht für virtualenv entweder. Meine Vermutung mag historisch falsch sein, aber da ich sowohl mit rbenv als auch mit virtualenv , kann ich Ihnen sagen, dass sich virtualenv entweder wie eine schlechte Kopie ohne Verständnis anfühlt, oder vielleicht ein früher Prototyp, der um rbenv verbessert wurde. In jedem Fall ist virtualenv im Vergleich zu rbenv ein Gespött, und hier ist der Grund:

Es kopiert Pakete für jede Umgebung. Das ist dumm, langsam und verwirrend. Es ist nur eine schlechte Design-Entscheidung, aber wahrscheinlicher nur ein Mangel an Entscheidung: Es ist einfach so passiert, weil jemand Code geschrieben hat, um diese Pakete in ein beliebiges Verzeichnis zu legen. Außerdem funktioniert es unter Windows nicht wirklich. Bis zu dem Punkt, dass es nie wirklich unter Windows getestet wurde ... Eine lächerliche Sache daran ist, dass es für das Betriebssystem testet und sobald es entdeckt, dass es unter Windows läuft, setzt es das Home-Verzeichnis auf ~ , diese Standardeinstellung kann später von einigen Umgebungsvariablen überschrieben werden, aber wenn Sie tatsächlich versuchen, Ihre Automatisierung in einer überwachten und sauberen Umgebung auszuführen ... virtualenv wird die Pakete einfach nie im selben Verzeichnis installieren.

Also... pipenv behauptet, ein Werkzeug für Menschen zu sein, so ähnlich wie requests ... denke ich? Es sollte also die unreifen Bemühungen seiner Vorgänger verbessern ... nun, es scheint der richtige Weg zu sein, wenn Sie ein Programm erstellen möchten, das dasselbe tut wie die Vorgänger, aber besser, richtig ? Und doch, anstatt den Müll von virtualenv wegzuwerfen, verwendet es ihn so wie er ist. Der Wrapper unterscheidet sich vom verpackten Programm nur darin, dass er die Verwendung einiger Funktionen des verpackten Programms nicht zulässt / erschwert...

In meinem Leben habe ich viele Versuche zur Automatisierung gesehen, die scheiße waren, aber ihr strebt nach den Sternen, ihr stellt all diese unverdienten Bewertungen auf eure Seite, noch bevor ihr irgendwelche nützlichen Informationen veröffentlicht. Aber Sie halten das Versprechen nicht. In Wirklichkeit manipuliert man einfach die öffentliche Meinung, ohne wirkliche Arbeit zu leisten. Und jetzt müssen sich Programmierer, die automatisieren müssen, einem weiteren Übel stellen, nur weil jemand mehr "Likes" auf GitHub bekommen wollte...

@wvxvw Tatsächlich fünf (vier, siehe unten) Jahre älter als rbenv und kann daher nie davon inspiriert werden. Außerdem sind es grundverschiedene Dinge, die nur am Ende ein ähnliches Ziel erreichen. Das, wonach Sie suchen (von rbenv inspiriertes Laufzeitverwaltungstool) ist pyenv.

Auch im Hinblick darauf, dass virtualenv nicht mit anderen Tools vergleichbar ist – wissen Sie, dass es es seit zehn (10) Jahren gibt? Die Anforderungen an die Softwareentwicklung ändern sich stark, und die von ihr gemachten Annahmen sind allmählich veraltet, und niemand hat sich die Mühe gemacht, sie zu ersetzen. Kümmerst du dich genug, um aufzusteigen?

Ich verstehe, dass jeder eine Gelegenheit verdient, etwas zu sagen, aber sich an einer Diskussion ohne minimales Verständnis des Themas anzuschließen und sofort mit dem Finger zu zeigen, ist dies für Mitwirkende von Pipenv-, Virtualenv- und Python-Paketsystemen insgesamt ziemlich unhöflich. Bitte mach das nicht.

Edit: Ich habe etwas gegraben. Die erste Version von virtualenv, 0.8, wurde im Jahr 2007 veröffentlicht, die von rbenv (0,1) war 2011, also liegen sie vier Jahre auseinander, nicht fünf.

@wvxvw Ich habe nur gesehen, wie Sie Beleidigungen angeboten haben. Diese Art von Haltung ist hier nicht wirklich willkommen. Bitte lesen Sie unseren Verhaltenskodex, bevor Sie mit dem Posten fortfahren.

Ich habe das gleiche Problem, nachdem ich den Projektpfad geändert habe und das ursprüngliche Virtualenv-Mapping verloren habe, dann habe ich diesen Thread gelesen. Zunächst einmal schätze ich die Arbeit des pipenv-Teams. Ich habe gerade ein paar Meinungen, die ich zu dieser Diskussion teilen möchte:

1. Das Dokument sollte tatsächlich auf den Zuordnungsmechanismus zwischen Projektpfad und Umgebung hinweisen, zumindest die Benutzer warnen, dass changing project path would cause unmapping the original env .

2. Ist es besser, wenn Sie den Pfad zum env im Pipfile manuell setzen können? Ich meine, die Leute haben möglicherweise einige spezielle Anforderungen, um dieselbe Umgebung manuell zu verwenden.

Nur meine Meinung, um sie mit euch zu teilen.

Es ist völlig unklar, wie man pipenv verwendet. Sollte ich viele virtuelle Umgebungen für ein Projekt haben? Soll ich die virtuellen Umgebungen zwischen Projekten teilen? Wie installiere ich mit pipenv eine andere Python-Version für ein bestimmtes Projekt, wenn die Python-Version nur für dieses Projekt benötigt wird? Jeder ist in diesem Thread so von sich selbst erfüllt, nimmt eine Menge Dinge über andere Leute an und versucht nie zu verstehen, woher andere kommen. Als ich auf der Homepage das Lob von pipenv las, glaubte ich, dass es mir helfen wird. Stattdessen habe ich 5 Tage damit verschwendet, damit zu ringen, und jetzt denke ich, dass ich zurück zu Pyenv gehe, weil das zumindest etwas deterministisch war.

Wenn Sie mehrere Umgebungen für ein Projekt verwenden möchten, verwenden Sie tox. Verwenden Sie pipenv für Ihre Hauptentwicklungsumgebung und tox zum Testen auf mehreren Python-Versionen.

@ashnur, du musst eindeutig etwas tun. Anstatt Negativität unter einem von Freiwilligen betriebenen Open-Source-Projekt zu verbreiten, warum versuchen Sie nicht, etwas Nützliches beizutragen?

@uranusjr
Dies ist , wo das Hashing geschieht?

Ich arbeite an einem Projekt und muss den Hash eines Pfads berechnen.

@devxpy Ja , genau.

Ich denke, Sie sollten ein grundlegendes Tutorial zum Einrichten eines Virtualenv mit Pipenv erstellen Sprachen oder Methoden, um ihre Projekte zu erstellen

@uranusjr Was ist der Grund, warum Pipenv die virtualenv nicht standardmäßig im Projektverzeichnis erstellt? So wie ich es sehe, würde es das Problem mit verwaisten Umgebungen lösen, wenn das Projekt umbenannt/verschoben/gelöscht wird. Außerdem wäre es weniger verwirrend für Leute, die (zu Recht) erwarten, dass es wie npm funktioniert.

Gibt es einen Vorteil, diesen Ansatz neben vielleicht der Tradition zu bevorzugen?

Erstellen Sie einfach das .venv-Verzeichnis vor dem Befehl pipenv install. Eine Option —venv oder —dot-venv für die Installation von pipenv wäre eigentlich willkommen :)

Ab 2018.10.9 gibt es eine andere Möglichkeit, dies zu tun. Sie können eine .venv Datei hinzufügen, die den Pfad zu Ihrer virtuellen Umgebung enthält. (Hinterhältiges neues Feature!)

@andrewpeterprifer Weil wir das früher gemacht haben und es ändern mussten, weil einige Leute sehr stark abgelehnt haben. Wir müssen uns für den einen oder anderen Ansatz entscheiden, und ich musste zugeben, dass es die bessere Standardeinstellung ist, keine virtuellen Umgebungen in das Projektverzeichnis zu legen.

ps Wären Sie (oder jemand) daran interessiert, einen FAQ-Eintrag zu diesem Thema zu schreiben? Es würde wahrscheinlich ein paar Absätze dauern, aber ich würde Ihnen gerne erklären, wenn jemand verspricht, sich die Zeit zu nehmen, den Text zu polieren und eine PR einzureichen.

@uranusjr Ich bin super neugierig, warum es eine bessere Standardeinstellung ist. Ich bin ein relativer Python-Neuling und jetzt habe ich das Gefühl, dass mir etwas Offensichtliches an Best Practices fehlt. :) Danke!

PS.: Ich könnte einen FAQ-Eintrag schreiben, wenn Sie erklären, warum die Dinge so sind, wie sie sind. ;)

Ab 2018.10.9 gibt es eine andere Möglichkeit, dies zu tun. Sie können eine .venv _file_ hinzufügen, die den Pfad zu Ihrer virtuellen Umgebung enthält. (Hinterhältiges neues Feature!)

@andrewpeterprifer Weil wir das früher gemacht haben und es ändern mussten, weil einige Leute sehr stark abgelehnt haben. Wir müssen uns für den einen oder anderen Ansatz entscheiden, und ich musste zugeben, dass es die bessere Standardeinstellung ist, keine virtuellen Umgebungen in das Projektverzeichnis zu legen.

ps Wären Sie (oder jemand) daran interessiert, einen FAQ-Eintrag zu diesem Thema zu schreiben? Es würde wahrscheinlich ein paar Absätze dauern, aber ich würde Ihnen gerne erklären, wenn jemand verspricht, sich die Zeit zu nehmen, den Text zu polieren und eine PR einzureichen.

Es tut mir leid, dass ich hier reinstoße ... Ich habe genau das gleiche Bedürfnis, Projektordner zu verschieben, die eine mit pipenv erstellte virtuelle Umgebung haben.

Zur Zeit mache ich folgendes und habe überhaupt kein Problem:

• Ich verschiebe den Projektordner wohin ich will
• in C:\Users\user\.virtualenvs lösche ich den Ordner des venv, der mit dem Projekt verknüpft ist, das ich gerade verschoben habe
• Ich navigiere über cmd zum neuen Projektordner und führe pipenv install (oder pipenv-Shell und dann pipenv sync) aus.

Alles funktioniert in Ordnung. Ist das eine schlechte Praxis?

Bezüglich des @uranusjr- Kommentars, wenn ich das neue Feature richtig verstehe, sollte ich die .venv-Datei (die den Pfad zur gewünschten virtuellen Umgebung enthält) in den Projektordner einfügen, oder? Und das würde es mir ersparen, alle Schritte, die ich zuvor erwähnt habe, durchführen zu müssen? Wenn ja, ist es großartig!!
Wäre es dann nicht besser, wenn eine solche Datei beim erstmaligen Anlegen der virtuellen Umgebung automatisch im Projektordner erstellt würde?

PS: Ich bin auch bereit, eine FAQ zu schreiben

Eigentlich finde ich die Idee von .env Datei unter dem Projekt-Root generieren und enthält Umgebungskonfigurationen wie PATH . Es wird die Umgebung für Entwickler transparenter machen und eine bequemere Möglichkeit zur Neukonfiguration bieten.

Ich werde versuchen, Ihre Fragen gemeinsam zu beantworten. Der Ansatz ist nicht schlecht (IMO; ich verwende auch das gleiche Setup). Es ist jedoch für einen unwissenden Benutzer einfacher, darauf zu stolpern.

Eine Möglichkeit wäre, ein Projekt in die Versionskontrolle zu stellen (z. B. Git). Wenn die Umgebung im Projekt-Root erstellt wird, befindet sie sich natürlich im Repository-Root. Leute wie Sie und ich, die an dieses Setup gewöhnt sind, wissen offensichtlich, dass wir eine Regel in .gitignore (oder der globalen Ignore-Konfiguration) hinzufügen sollten, um zu verhindern, dass das Verzeichnis .venv eingecheckt wird, aber ein ahnungsloser Benutzer würde dies nicht tun und könnte sehr leicht versehentlich in der Umgebung nachsehen. Dies ist nicht nur schlecht für das Projektmanagement, sondern (was noch wichtiger ist) bietet einen Vektor für potenzielle Angriffe, indem lokale Informationen preisgegeben werden. Daher ist es eine allgemeine Regel für Projektmanagement-Tools , generierte Dateien nicht im Projektverzeichnis abzulegen . Es könnte in Ordnung sein (immer noch nicht optimal IMO), dies zu tun, wenn Sie ein Ökosystem von Grund auf neu entwerfen (z. B. node_modules NPM), aber definitiv keine gute Idee für Tools, die für ein Ökosystem mit etablierten gängigen Praktiken entwickelt wurden. wie im Fall von Pipenv.

Wenn eine Umgebung standardmäßig außerhalb des Projektstamms generiert wird, müssen Sie sich beim Veröffentlichen Ihres Projekts (zB per Push auf GitHub) um eine Sache weniger kümmern. Es macht unser Leben (die projektinterne Umgebungen bevorzugen) etwas schwieriger, aber aus Risikosicht ist das Schlimmste, was passieren kann, das Projekt versehentlich zu verschieben und die Umgebung zu zerstören oder vergessen, eine Umgebung zu entfernen, wenn ein Projekt entfernt wird . Beides lässt sich viel, viel leichter wiederherstellen, als Ihre potenziell sensiblen Umgebungsinformationen versehentlich an GitHub zu übertragen.

Die .venv ist noch ziemlich neu (erst vor wenigen Tagen veröffentlicht), und wir suchen noch nach Wegen, sie am besten zu nutzen. Es hat immer noch das gleiche Problem eines .venv Verzeichnisses, aber hoffentlich nicht so schlimm. Ich selbst mag die Funktion sehr und hoffe auf jeden Fall, dass wir sie nutzen können, um die Benutzererfahrung zu verbessern, aber hier gibt es noch viel zu beachten.

Hallo. Für mich sind das .venv-Verzeichnis (alte Funktion) und die .venv-Datei (neue Funktion) in Ordnung, aber ich wäre sehr dankbar, wenn ich eine Option im Befehl pipenv install hätte.

Etwas wie:

pipenv install

Würde in ~/.local/ installieren

pipenv install --venv

Würde im Verzeichnis $PWD/.venv installieren

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

Würde in /my/custom-path installieren.

Wenn Sie eine neue Funktion wünschen, schlagen Sie sie bitte richtig vor, indem Sie einen Verbesserungsvorschlag für ~/.peeps . Bitte machen Sie keine Verbesserungsvorschläge, die zufällig über verschiedene Probleme verstreut sind, da sie nicht nachverfolgt werden können.

@uranusjr danke für die ausführliche Antwort! Nur um meine Neugier zu befriedigen, welche Art von lokalen (potenziell sensiblen) Informationen könnte von einem eingecheckten Python-Venv offengelegt werden? Ich stimme zu, dass es ärgerlich ist, wenn node_modules eingecheckt wird, aber normalerweise würde das keine lokalen Informationen enthalten.

Virtuelle Python-Umgebungen enthalten mehrere Shell-Skripte (zB activate ). Viele Leute ändern sie, um Umgebungsvariablen hinzuzufügen, um Datenbankpasswörter, den Pfad zu einer anderen Konfigurationsdatei usw. anzugeben. Das Ändern von Skripten in virtuellen Umgebungen verstößt gegen die bewährte Vorgehensweise, aber die Leute tun dies trotzdem (und werden defensiv, wenn Sie ihnen sagen, dass sie damit aufhören sollen -persönliche Erfahrung).

Außerdem haben Sie Recht, node_modules wahrscheinlich keine sensiblen Informationen. Das ist ein weiterer Vorteil, wenn Sie ein Ökosystem von Grund auf neu aufbauen. Virtuelle Python-Umgebungen wurden leider schon lange erfunden, bevor dies ein weit verbreitetes Problem ist (damals sind Sie bereits ein Guru, wenn Sie VCS überhaupt verwenden).

Ich bin hier angekommen, als ich versuchte zu verstehen, woher pipenv das richtige Virtualenv kennt :)

Danke Jungs für diese Diskussion. Wahrscheinlich könnte es eine gute Idee sein, auf der Hauptseite (zB hier ) anzugeben, dass das Umbenennen des Projektpfads den Standardmechanismus der Virtualenv-Bindung unterbricht.

Alle Dokumentationsseiten sind offen für Beiträge. Frag nicht nach Dingen, tu es :)

Ich werde!

@uranusjr Dies bedeutet, dass die virtualenv meines Projekts verloren geht, wenn ich das Verzeichnis umbenenne. Das ist schlecht. Es kann ein häufiger Anwendungsfall sein, ein Verzeichnis umzubenennen, und Benutzer können darauf hereinfallen und sich fragen, warum ihre Umgebung nicht mehr funktioniert.

Ich würde vorschlagen, es zu beheben und einen Eintrag in Pipfile vorzunehmen, wenn dies möglich ist. Oder erstellen Sie eine weitere .pipenv-Datei, um solche Metadaten in jedem Projektverzeichnis zu speichern.

Was schlagen Sie vor ?

Danke für die Beantwortung der beiden Fragen!

danke, dass du die beiden Fragen gestellt hast. ich habe auch das gleiche problem,

Wenn Sie pipenv in einem falschen Verzeichnis initialisiert haben und das virtualenv-Verzeichnis aus dem richtigen Verzeichnis verwenden müssen, können Sie den virtualenv-Pfad erhalten, indem Sie pipenv --venv ausführen und die PIpfile und Pipfile.lock in das richtige Verzeichnis.

echo ${PATH_OBTAINED_FROM_PREVIOUS_COMMAND} > .venv im richtigen Verzeichnis und es sollte richtig funktionieren.

Mir ist heute aufgefallen, dass pipenv die Umgebungsvariable export PIPENV_VENV_IN_PROJECT=1 ignoriert, wenn sich eine pipfile im übergeordneten Verzeichnis befindet, und stattdessen eine venv im übergeordneten Verzeichnis installiert. Dies ist bei der Veröffentlichung 2018.11.26 . Wenn Sie die pipfile aus dem übergeordneten Verzeichnis entfernen, funktioniert pipenv wie dokumentiert.