Ein ambitionierter Vorschlag!

ini-Konfigurationsunterstützung (eine globale ini-Konfiguration, die im Benutzerhaus vorhanden ist)

Ziehen Sie in Erwägung, appdirs (oder ähnliches) zu verwenden, um die Konfiguration an plattformbevorzugten Speicherorten zu ermitteln.

appdirs könnte eine Option sein, aber dann müssten wir damit beginnen, Dinge in unser Paket aufzunehmen. Um fair zu sein, 70 % davon sind bereits erledigt, es bräuchte nur eine bessere Reorganisation.

Warum Anbieter anstatt nur davon abhängig zu sein? (Nicht, dass es schwer zu verkaufen wäre, es ist nur eine einzelne Datei). IMO, wir müssen wirklich akzeptieren, dass (mit Ausnahme von pip) Verpackungstools wirklich wie jede andere Anwendung erstellt werden sollten. Wenn Abhängigkeiten so schwer sind, dass PyPA-Apps sie vermeiden, was sagt das darüber aus, wie gut wir unseren Benutzern die Entwicklung von Anwendungen erleichtern?

(Entschuldigung, ich mache hier keinen großen Punkt über virtualenv, ich sehe nur so viele Leute, die sagen "Das Hinzufügen einer PyPI-Abhängigkeit ist keine große Sache", dann wundern mich die PyPA-Tools, an denen ich arbeite. .

Ohne Vendoring wird die Cross-Interpreter-Funktion meiner Meinung nach schwer. ZB Erstellen einer virtuellen Umgebung für einen Interpreter, auf dem virtualenv nicht installiert ist.

PYTHONPATH=/t/path/to/virtualenv.whl python -m virtualenv

Äh, das würde bedeuten, dass wir uns nicht auf zusätzliche Pakete von virtualenv verlassen können. Da wir eine Zip-App bereitstellen werden, welche Anwendungsfälle ermöglicht dies?

@gaborbernat Du meinst die Option -p ? Ich denke schon. Es scheint genau die Art von Situation zu sein, bei der Zipapps helfen sollten, aber niemand hat jemals wirklich viel getan, um die Details zu erläutern, damit es gut funktioniert.

Von @pradyunsg :

Äh, das würde bedeuten, dass wir uns nicht auf zusätzliche Pakete von virtualenv verlassen können

Wie @gaborbernat sagte, impliziert die Option -p wahrscheinlich, dass :-( Aber ich frage mich, warum wir die Option "Rad auf PYTHONPATH " sowie die Zipapp-Option brauchen - besonders angesichts der Räder on PYTHONPATH werden im Allgemeinen nicht unterstützt (wir verwenden sie intern in virtualenv aus den üblichen Pip-Bootstrapping-Gründen - pip ist so ziemlich eine Ausnahme von allem ;-))

zweijährige Nachfrist für die Unterstützung

Hmm...

Meine Sorge hier ist, dass die Netzwerkeffekte dies zu einer Verlangsamung der Einführung neuerer Versionen von Python und einer kombinatorischen Explosion der Anzahl unterstützter Pythons führen könnten. CPython diskutiert unterschiedliche Release-Kadenzen für 3.9, daher könnten 2 Jahre sogar länger sein als das, was einige Releases von Core-Entwicklern haben könnten.

Das heißt, ich möchte das nicht blockieren, sondern vor allem sicherstellen, dass ich sage, dass ich nicht daran interessiert bin.

(in der Hoffnung auf IronPython und Jython irgendwann - irgendwelche anderen, die wir unterstützen sollten?)

Bestimmt. @gaborbernat weiß wahrscheinlich, dass ich das sagen würde - diese wären gut zu haben, aber ich bin mir ziemlich sicher, dass Leute, die mit der Implementierung vertrauter sind, am besten dafür geeignet sind. Zumindest was die langfristige Unterstützung angeht und im Idealfall auch die Arbeit, es überhaupt erst gut zu unterstützen (CI, Tests etc.).

erstens, ini-Konfigurationsunterstützung (eine globale ini-Konfiguration, die im Benutzerhaus vorhanden ist),

Ich bin voreingenommen – ich würde es wirklich gerne sehen, dass dies stattdessen TOML ist. :)

(Ich habe das noch nicht ganz verarbeitet, da ich irgendwo hin muss - aber das sieht nach einem tollen Gesamtziel aus!)

Wir können uns aufgrund der Cross-Interpreter-Funktion ohnehin nicht wirklich auf zusätzliche Pakete verlassen, daher betrachte ich dies nicht als großen Nachteil, und ich möchte eine einfache Möglichkeit haben, virtuelle Umgebungen ohne Installation/Abhängigkeit zu betreiben (benötigt, wenn Leute rufen Sie uns aus Knotenpaketen auf). Angesichts der Tatsache, dass es uns nicht viel kostet, bietet das Angebot außer Zipapp scheint billig zu sein.

bevorzuge eingebautes venv: Wenn das Zielpython venv hat, erstellen wir die Umgebung damit (und führen dann nachfolgende Operationen darauf durch, um andere von uns angebotene Garantien zu ermöglichen).

Ich bin mir nicht sicher, ob ich den Grund dafür verstehe. Es scheint , wie es wird die Wartung von machen virtualenv härter und es wird das Verhalten schwieriger für die Endnutzer verständlich machen. setuptools geht bereits in die andere Richtung, indem es versucht, distutils zu absorbieren, anstatt es weiter zu flicken.

@pganssle der Umfang ist anders und der Problemraum auch. virtualenv Problem ist, dass Systeme oft zusätzliche Einschränkungen für Systempakete auferlegen, so dass sie das eingebaute venv patchen, um diese einzuhalten. All dies zu replizieren wäre schwierig, siehe zB #1362.

FWIW Ich denke, die Verwendung des eingebauten venv Pakets für die Isolierung ist die richtige Idee, es ist in den eigentlichen Interpreter integriert (und nicht in distutils, das nur ein stdlib-Modul ist), sodass es viel sauberer als virtualenv kann.

Virtualenv müsste auch nichts monkeypatchen, es würde nur die öffentliche API verwenden, was in Ordnung sein sollte.

FWIW Ich würde empfehlen, meinen alten rewrite virtualenv-Zweig zu überprüfen, er hat viele dieser Dinge bereits getan.

Ich würde wahrscheinlich vorschlagen, dass ein Plugin-System für virtualenv nicht besonders nützlich ist. Höchstens gibt es wahrscheinlich nur einen Hook, einen Post-Erstellungsschritt und selbst dann können Sie wahrscheinlich nur eine Liste der zu installierenden Dinge haben.

AUCH, Sie können sich "natürlich" immer noch auf Dinge verlassen und Zipapps verwenden, Sie müssen nur innerhalb der Zipapp selbst einen Anbieter anbieten. Ich würde empfehlen, sich von der Option zum erneuten Ausführen unter Target-Python zu entfernen, dies ist eine schlechte Sache und kann viel sauberer durchgeführt werden.

697 -- @dstuffts ältere PR

PYTHONPATH=/t/path/to/virtualenv.whl python -m virtualenv

OTOH, wir sollten das wahrscheinlich sowieso nicht tun -- https://www.python.org/dev/peps/pep-0427/#is -it-possible-to-import-python-code-directly-from- a-wheel-feile

@pradyunsg also andere Methoden zum Bootstrapping von Pip, ohne das Rad auf den Weg zu stellen?

Bootstrapping pip ist wahrscheinlich in Ordnung - es wird jetzt von virtualenv verwendet ¹ . Aber ich würde stark nur empfehlen es für pip verwenden und nicht als Mittel der laufenden virtualenv selbst.

¹ Aber ich würde jede komplizierte Funktionalität vermeiden - die Verwendung eines Rads auf PATH zum Installieren von Pip von diesem Rad ist so ziemlich garantiert in Ordnung. Aber Sie könnten Probleme haben, wenn Sie beispielsweise mit einem solchen Rad auf das Internet zugreifen, da ich denke, dass certifi sein eingebettetes Zertifikatspaket als tatsächliche Datei benötigt (aber ich kann mich irren, das hat mir nie ein Problem bereitet, aber ich weiß get-pip.py extrahiert die Zertifikate explizit aus dem Rad, um diesen Punkt zu adressieren.

Gibt es einen Grund, warum wir Pip nicht als zipapp versenden? Das würde diese Notwendigkeit vermeiden, wie ich es verstehe, und Zipapp wird von Python 2.7 unterstützt

@gaborbernat hast du es probiert? funktioniert es? Wenn der von Ihnen beschriebene Ansatz unter Windows funktioniert, habe ich zunächst keine Bedenken, aber @uranusjr hätte wahrscheinlich Feedback. Meine einzigen Kommentare stimmen mit

Gibt es einen Grund, warum wir Pip nicht als Zipapp versenden?

Denn in bestimmten Fällen wird pip nicht direkt von einer Zip-Datei (oder einem Rad, es ist dasselbe) ausgeführt, wie ich oben sagte. In 99% (Alarm - erfundene Zahl) funktioniert es, aber manchmal ist die Tatsache wichtig, dass das Zertifikatspaket eine echte Datei sein muss.

Es würde wahrscheinlich gut funktionieren, Pip als Shiv zu bündeln, da Shiv die Zipapp entpackt, bevor sie ausgeführt wird, genau um die Eckfälle zu vermeiden, in denen das Laufen von einem Reißverschluss bricht. Das hat meines Wissens aber noch niemand probiert.

Wie üblich sind die Hauptgründe, warum dies nicht passiert ist:

1. Niemand dachte daran.
2. Niemand hatte die Zeit/Motivation dafür.
3. Der aktuelle Ansatz funktioniert gut, und es gibt größere Fische zum Braten.

Gibt es also andere Methoden zum Bootstrapping von Pip, ohne das Rad auf den Weg zu stellen?

Ich glaube nicht, dass wir das hier brauchen - virtualenv verwendet das Pip-Rad, um IIRC von selbst zu installieren, was gut funktionieren sollte. Wie @pfmoore sagte, ist das einzige "Extra", das get-pip.py tut, die Zertifikate auszupacken und einen Pfad zu ihnen bereitzustellen. Da der Anwendungsfall von virtualenv das Netzwerk nicht erreicht, müssen wir hier nichts Neues tun.

Der aktuelle Ansatz funktioniert gut, und es gibt größere Fische zum Braten.

Dies, viel mehr als die anderen IMO. Wir könnten, aber es gibt noch wirkungsvollere Probleme, die wir angehen müssen. :)

Ich hatte einmal einen PR, der pip als Zip-App erstellte, es funktionierte, aber IIRC musste ich Änderungen an pip vornehmen, um es voll funktionsfähig zu machen.

Das könnte jetzt etwas kompliziert sein, da pip sich selbst als Unterprozess von sich selbst für PEP 517 aufruft. Ich bin mir nicht sicher, aber das ist definitiv eine Erkundung wert.

An diesem Punkt wäre shiv (oder eine andere selbstextrahierende Option) besser für Pip geeignet, als zu versuchen, Pip in zip-runnable umzuwandeln. Aber ich denke, das ist jetzt nicht besonders wichtig. surepip geht bereits den Rad-auf-Pfad-Weg, warum nicht einfach das Gleiche tun. Alternatives Pip-Bootstrapping kann erforscht werden, nachdem wir alle größeren Fische gebraten haben, und möglicherweise wieder in stdlib eingebracht werden.

Alternatives Pip Bootstrapping kann erforscht werden, nachdem wir alle größeren Fische gebraten haben

Klingt nach einem Plan [einer, dem wir bereits folgen. ;)]

Vielen Dank für die Links, basierend auf dem Feedback, das ich unter https://github.com/gaborbernat/virtualenv/tree/rewrite/src/virtualenv mit einigen ersten Arbeiten begonnen habe 20.0.0 .

+1 für die Verwendung von venv, falls vorhanden. Das würde den Anwendungsfall von PyPy einfacher machen.

Die Neufassung hat also einen Zustand erreicht, in dem ich mich wohl fühle, wenn die Leute sich das ansehen und Feedback geben. Bitte kontaktieren Sie mich, wenn Sie etwas Freizeit haben, um dabei zu helfen; die Veröffentlichung ist bis Ende des Monats geplant 🤞 Hinweis https://github.com/pypa/virtualenv/milestone/7 muss noch umgesetzt werden, aber die Kernidee ist da.

PS. Feedback-PR erstellt unter https://github.com/pypa/virtualenv/pull/1481/

Funktionsanforderung: Stellen Sie einen Mechanismus zum Definieren benutzerdefinierter Umgebungsvariablen bereit, indem Sie beispielsweise eine env.txt Datei im venv-bin-Verzeichnis mit dem Standardformat ablegen:

VARNAME=value
OTHERVAR=othervalue

Ich glaube, ich verstehe deinen Anwendungsfall nicht? Wie würden diese Umgebungsvariablen verwendet, wann festgelegt?

Bearbeiten. NM. Ich sehe Sie erweitert auf https://github.com/pypa/virtualenv/issues/1124.

Ein kleines Update; Ich habe es geschafft, die meisten Blockierungsprobleme zu schließen, außer zwei, die noch etwas Liebe erfordern: Das Testen umfasst Header + Zwischenspeichern von Python-Abfrageaufrufen mit einer Sperre auf die App-Daten, sodass wir virtuelle Umgebungen parallel erstellen können (an verschiedenen Standorten). Beim aktuellen Tempo komme ich vielleicht ein paar Tage zu spät... sollte aber definitiv bis zum 7. Februar draußen sein.

Wie sehen wir den Rollout aus? Würden wir eine Beta vor der Hauptversion veröffentlichen?

Ja, ich möchte am Montag etwas rausbringen... Und dann versuchsweise eine Woche Zeit für Feedback, Fixes... Und dann Master durch Rewrite und Release ersetzen.

Ich bin mir nicht 100% sicher, ob eine Woche ausreichen würde, und wir sollten auf jeden Fall über mehrere Kanäle kommunizieren, dass die Leute die Beta ausprobieren sollen.

Das Stichwort dort war vorläufig . Ich bin hier optimistisch, angesichts des Aufwands, den ich investiert habe, erwarte ich keine größeren Probleme, aber

virtualenv 20.0.0 beta1 ist verfügbar .

Da die Beta verfügbar ist, habe ich das Gefühl, dass dieses Problem dem Zweck dient. Ich schließe und wir können mehr konzentriert auf spezielle Themen diskutieren.