Pipenv: Verwenden Sie venv anstelle von virtualenv, falls verfügbar

ich glaube nicht, ich bevorzuge es, den virtualenv-Befehl persönlich zu verwenden

Vielleicht ist es aber möglich, dass beide Optionen nebeneinander existieren? Wenn ich beiläufig durch die Quelle stöbere, sehe ich nichts, was speziell mit Virtualenv verbunden ist, außer dem Befehl, der zum Erstellen der Umgebung verwendet wird. Virtualenv kann immer der Standard sein, aber der Benutzer kann (zum Beispiel) --venv um .venv mit python3 -m venv anstelle von virtualenv .

Ich würde mich ehrlich gesagt ausschließlich auf pipenv verlassen und es wäre mir egal, ob virtualenv oder venv verwendet würde, aber ich dachte, wir könnten Built-Ins nutzen, wenn sie verfügbar sind.

Ich fordere @kennethreitz auf, seinen Kommentar hier zu überdenken. Die Verwendung von python3 -m venv anstelle von virtualenv wird von der Standarddokumentation empfohlen. Ich persönlich schrecke ab, pipenv zu verwenden, weil es virtualenv verwendet. Ich benutze nur Python 3 und verwende heutzutage nur noch venv .

@bulletmark Da venv (berdario/pew#67), also besteht immer noch eine Chance. Wenn Pew es zum Laufen bringen kann, wäre es viel einfacher (und zumindest für mich sinnvoller), die venv Unterstützung in Pipenv zu implementieren.

@uranusjr klingt großartig!

Ich persönlich habe venv nie benutzt, daher meine Besorgnis. Aber ich bin sicher, es ist gut.

Die Dinge laufen gerade gut. Keine Notwendigkeit, Dinge zu ändern, die nicht kaputt sind.

Schließlich fand ich diesen Thread , weil mein System defekt ist.

Wenn Sie eine Umgebung mit virtualenv in Python 3.X erstellen und dann auf Python 3.Y aktualisieren, ist die virtualenv kaputt, weil Sie wissen, dass Python die Shared Libraries nicht mehr benötigt. Mit venv Sie einfach python3 -m venv --upgrade ausführen.

Das wäre ein nettes Feature.

Das wäre auf jeden Fall schön und fühlt sich in die Richtung von Python an

venv nicht zu verwenden (und stattdessen virtualenv zu verwenden) ist für mich ein totaler Showstopper - ich kann Pipenv nicht verwenden. Ich kann virtualenv nicht verwenden, da es frustrierend ist, die Python-Binärdatei zu kopieren und dennoch von gemeinsam genutzten Bibliotheken abhängig ist - wie Dhouck oben zu seinem Missfallen oben festgestellt hat. Dies bricht virtualenvs die ganze Zeit (wenn das System-Python aktualisiert wird und die Binärdatei baumeln lässt) und kopiert die Python-Binärdatei unnötigerweise ohne jeglichen Nutzen.

Wenn pipenv die Zukunft von Python ist, sollte es standardmäßig venv auf Python 3 verwenden (und warnen, wenn es nicht verwendet wird). Es ist in Python 3 integriert und das empfohlene Tool. Es ist sehr seltsam, dass Pipenv jetzt auch ein empfohlenes Tool ist, aber es verwendet kein venv.

Da venv von Natur aus Teil von Python selbst ist, hat es Zugriff auf die Interna von Python, was bedeutet, dass es die Dinge mit viel weniger Hacks richtig machen kann. Zum Beispiel muss virtualenv die Python-Interpreter-Binärdatei in die virtuelle Umgebung kopieren, um sie zu glauben, dass sie isoliert ist, während venv einfach eine Konfigurationsdatei verwenden kann, die von der Python-Binärdatei an ihrem normalen Speicherort gelesen wird, damit sie weiß, dass sie handeln soll wie in einer virtuellen Umgebung. venv kann man sich vorstellen, dass virtualenv richtig gemacht wurde, mit dem Segen und der Unterstützung der Python-Entwickler.

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

Ich habe mit berdario/pew#173 begonnen, hatte aber nicht viel Zeit, um Fortschritte zu machen. Wie oben erwähnt, unterstützt Pipenv dies automatisch, sobald Pew dies tut. Ich hätte gerne Hilfe, falls jemand daran interessiert ist, venv zu Pipenv zu bringen. Das Hauptproblem wäre jetzt, die Tests zu bestehen.

Kurzes Update zur venv-Unterstützung: Es wird zumindest in naher Zukunft nicht passieren. venv ist einfach nicht gut genug, um dies zu erreichen. Wenn Ihnen das wirklich wichtig ist, gehen Sie zum Python-Bugtracker und helfen Sie selbst. Ansonsten bleib bei virtualenv .

venv ist das empfohlene Tool für Python, und es ist nicht defekt, wie es virtualenv ist (bezüglich: das Kopieren der Python-Binärdatei bricht dann ab, wenn die Python-Bibliothek aktualisiert wird). Der von Ihnen verlinkte Fehler betrifft die Kombination von venv und virtualenv, was nicht das ist, wonach wir fragen?

Leider ist es sehr üblich, dass Tools auf virtualenv aufbauen. Travis zum Beispiel verwendet virtualenv, um eine Build-Umgebung für Sie zu erstellen, wie vom ursprünglichen Reporter erwähnt. Es ist auch die Grundlage von Pipsi, die einer der empfohlenen Installationswege für Pipenv ist. Wenn Venv darin nicht gut funktionieren kann. Es ist an vielen Orten, ohne dass Sie es wissen. Die Venv-Unterstützung wäre halb kaputt und würde Sie auf unerwartete Weise beißen, wenn sie mit virtualenv nicht gut funktionieren würde.

Ich verstehe das, aber an dieser Stelle wird Pipenv empfohlen, und venv wird empfohlen, und sie stehen irgendwie in Konflikt. Es ist ein sehr seltsamer Zustand.

Ich stimme voll und ganz zu, dass es sich in einem seltsamen Zustand befindet, deshalb versuche ich, es zu reparieren :) Ich sage nicht, dass es nicht behoben wird, aber es müssen zuerst Änderungen im Upstream vorgenommen werden, und ich kann nichts tun, bis sie passieren. Ich poste den Link nicht als Entschuldigung, um die Arbeit einzustellen, sondern um die Leute wissen zu lassen, wo sie zuerst ihre Bemühungen unternehmen können, um diese Situation zu verbessern.

Vielleicht wäre es nicht allzu verrückt, dieses Thema dann offen zu halten?

Dies ist ein Kirchenbankproblem, kein Pipenv-Problem.

venv ist einfach nicht gut genug, um dies zu ermöglichen. Wenn Ihnen das wirklich wichtig ist, gehen Sie zum Python-Bugtracker und helfen Sie selbst.

Es ist kein Problem von venv, sondern von virtualenv. Ich habe einige Erklärungen unter dem Issue Tracker gepostet.
cc @uranusjr

Es gibt eine Umgehung ->
Verwenden Sie venv, um zuerst eine virtualenv zu erstellen, und führen Sie dann pipenv install . Beispielsweise:

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

🙈

Nur eine Notiz:

Die obige Problemumgehung funktioniert meistens, aber pipenv run ... schlägt für mich fehl, weil es kein activate_this.py unter .venv/bin . Glaubt man Ausgabe 21496 , ist nicht geplant, diese Datei zu venv hinzuzufügen. Selbst wenn pew dies behebt, würde pipenv wahrscheinlich immer noch ein Problem haben.

Mit virtualenv ist die Verwendung des System-tk-Moduls in macOS unmöglich. Aber mit venv ist es möglich.
Ich möchte unbedingt venv mit pipenv verwenden (kann optional sein).

Siehe auch: #1416

Um nicht zynisch zu klingen, aber ich möchte dringend, dass jemand den Code schreibt, um dies zu unterstützen, wenn es ihm wirklich so wichtig ist. Ich habe viele Leute getroffen, die sagten, dass sie das "stark" empfinden, aber soweit ich weiß, bin ich der einzige, der wirklich etwas tut. Und ich habe versagt. Dies ist nicht so einfach, wie Sie denken. Wenn Sie denken, dass Sie es besser können, tun Sie etwas. Wenn Sie nicht möchten, nehmen Sie bitte, was Sie bekommen können.

(kenneth und ich und wahrscheinlich erin und nate haben dies auch viel früher im projekt mit venv versucht und sind auch aus kompatibilitätsgründen gescheitert)

Das wäre schön, da sind sich alle einig. Ich würde gerne sehen, dass es plattformübergreifend und python-Versionen funktioniert.

Ich möchte noch auf einen weiteren Grund hinweisen, warum venv wahrscheinlich die bessere Wahl wäre als virtualenv:

Einer der hässlicheren Aspekte der Implementierung von virtualenv ist, dass es eine eigene Kopie des Site-Moduls haben muss, das für alle virtualenvs verwendet wird, unabhängig davon, mit welcher Python-Version sie erstellt wurden.
-- von https://github.com/pypa/virtualenv/issues/228#issuecomment -4165148

Dies bedeutet zum Beispiel, dass rlcompleter standardmäßig

Da dies ein Problem ist, das mehrere Ihrer Benutzer betrifft, würde ich außerdem vorschlagen, es offen zu lassen, bis das Problem behoben ist, auch wenn Sie darauf warten, dass vorgelagerte Änderungen vorgenommen werden.

Wieder. Wir wissen, dass es besser wäre. Es ist nicht wirklich möglich. Was hat Ihrer Meinung nach negativere Auswirkungen, wenn die Funktionalität für ein großes Segment von Benutzern vollständig unterbrochen wird oder einige Benutzer die Readline-Funktionen aktivieren müssen?

Ich bin sicher, das ist unpraktisch, es ist auch unpraktisch, dass es scheinbar nur Leute gibt, die dies fordern und doch niemand, der eine funktionierende Implementierung anbietet. Wir haben es versucht. Bis sich etwas drastisch ändert, haben wir keine Pläne, venv zu unterstützen und daher auch nicht vor, dieses Thema zu öffnen.

@techalchemy Wenn ich das richtig verstehe, ist pypa/virtualenv#1095 der richtige Ort, um dies zu diskutieren?

Scheint richtig zu sein, ich habe gesehen, dass Tox eine Problemumgehung hat, also würde das vielleicht funktionieren, wenn jemand es übertragen würde

Bank! was für eine diskussion.. wenn diese pew-Sache nicht so wichtig ist, wäre es dann möglich, sie zusammen mit virtualenv fallen zu lassen und pipenv, venv und python Hand in Hand gehen zu lassen, da sie sich alle gegenseitig empfehlen?

Abhängigkeitsmanagement-/virtuelle Umgebungslösungen für Python sind im Moment zu wildes Terrain, und imho müssen einige Opfer gebracht werden.

Dies könnte viele Leute erschrecken, die noch nicht bereit sind, mit virtualenv aufzuhören, aber es könnte für eines der kommenden Major Releases geplant werden (sofern technisch machbar). Änderungen sind unvermeidlich, es ist nur eine Frage der Zeit.

@doganmeh Wir können virtualenv ganz aufgeben und ein gleichwertiges Produkt erstellen, das nur Python 3.3 oder höher unterstützt, aber ich denke, es wäre einfacher, dieses andere Projekt zu erstellen.

Nur eine Notiz:

Die obige Problemumgehung funktioniert meistens, aber pipenv run ... schlägt für mich fehl, weil es kein activate_this.py unter .venv/bin . Glaubt man Ausgabe 21496 , ist nicht geplant, diese Datei zu venv hinzuzufügen. Selbst wenn pew dies behebt, würde pipenv wahrscheinlich immer noch ein Problem haben.

Ist das wirklich notwendig? Nachdem Sie mit venv eine virtuelle Umgebung erstellt haben, müssen Sie diese nicht mehr aktivieren, um sie zu verwenden. Sie führen einfach die Python-Binärdatei aus dem Verzeichnis venv/bin aus.

FWIW, das hängt zusammen (und was mich hierher gebracht hat): http://matplotlib.org/faq/osx_framework.html

In einem virtualenv wird ein Nicht-Framework-Build verwendet, selbst wenn die Umgebung aus einem Framework-Build erstellt wird ( virtualenv bug #54 , virtualenv bug #609 ) .

Die Lösung besteht darin, nicht virtualenv zu verwenden, sondern stattdessen das venv der stdlib , das eine ähnliche Funktionalität bietet, aber dieses Problem nicht aufweist.

Das Aufgeben der Python 2.7/virtualenv-Unterstützung klingt für mich nicht nach einer besonders schrecklichen Idee, wenn es pipenv , sich auf die stdlib einer Python-Version zu verlassen, deren Unterstützung nicht abläuft. Solange es keinen anderen Teil der pipenv Toolchain beschädigt, der für die Betreuer nicht leicht zu reparieren ist. Vielleicht sogar die 2.7-Unterstützung in einen separaten Zweig/Paket verschieben?

Ich würde gerne in der Lage sein, aktuellen Code beizutragen, aber ich glaube nicht, dass ich dazu die notwendige Erfahrung oder die Zeit habe :stirn: Das Beste, was ich tun kann, ist, die Diskussion im Moment zu unterstützen.

meine Stimme hier hinzufügen; Ich habe das gerade wegen des gleichen Problems wie @dmtucker getroffen .

Ich greife derzeit dazu, pipenv für dieses Projekt auf meinem Mac vollständig zu ignorieren und die Umgebung vorerst mit venv von Hand zu erstellen.

+1 um venv zu verwenden.
virtualenv hat viele Fehler, die nicht behoben werden .
pipenv völlig nützlich unter Windows 10 mit Python 3.7 aus dem Windows Store (virtualenv bug#1362 )

virtualenv wechselt zum venv-Modell - siehe https://github.com/pypa/virtualenv/issues/1366 , das pyvenv.cfg und all die guten Dinge generiert, also sollte dies damit gelöst werden.

---------- Weitergeleitete Nachricht ---------
Von: Dan Ryan [email protected]
Datum: Mo, 26.11.2018, 14:39 Uhr
Betreff: Re: [pypa/pipenv] Verwenden Sie venv anstelle von virtualenv, falls verfügbar (#15)
An: pypa/pipenv [email protected]
Cc: Abonniert [email protected]

Scheint richtig zu sein, ich habe gesehen, dass Tox einen Workaround hat, also würde das vielleicht funktionieren, wenn
jemand hat es portiert

—
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/15#issuecomment-441533872 oder stumm
der Faden
https://github.com/notifications/unsubscribe-auth/AqyQvrs-RNNTb1YhxaDCWDLpRxrZLKoxks5uy4ydgaJpZM4Lqk2f
.