Virtualenv: Skripte der Standardbibliothek in die Skripte von virtualenv aufnehmen

Tritt dies immer noch auf, nachdem Sie Pyenv Rehash durchgeführt haben?

Was führt der Shim aus, wenn er vor oder nach pyenv rehash ausgeführt wird?

Ich habe das Gefühl, dass dies etwas mit pyenv zu tun hat.

Tritt dies immer noch auf, nachdem Sie Pyenv Rehash durchgeführt haben?

Jawohl.

Was führt der Shim aus, wenn er vor oder nach pyenv rehash ausgeführt wird?

Da system Python ausgewählt wird, für das das Paket apt mit 2to3 nicht installiert ist, heißt es

pyenv: 2to3: command not found

The `2to3' command exists in these Python versions:
<list>

in beiden Fällen.

Ich habe das Gefühl, dass dies etwas mit pyenv zu tun hat.

pyenv ist irrelevant. Das erwartete Verhalten war, dass das zweite which den Shim virtualenv zurückgibt, wie es für python der Fall ist. Der Fehler ist, dass virtualenv keine erstellt. (Ich dachte, das wäre offensichtlich. Wahrscheinlich nicht.)

Ah, okay... Was ist PATH nach der Aktivierung?

(Ich bin nicht auf einem Computer, auf dem ich versuchen kann, dies jetzt zu reproduzieren.)

(test) vmuser<strong i="5">@ubuntuvm</strong>:~$ echo $PATH
/home/vmuser/test/bin:/home/vmuser/.rbenv/shims:/home/vmuser/.rbenv/bin:/home/vmuser/.pyenv/shims:/home/vmuser/.pyenv/bin:/home/vmuser/.local/bin:/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin:/usr/games:/usr/local/games:/snap/bin:/home/vmuser/.rvm/bin
(test) vmuser<strong i="6">@ubuntuvm</strong>:~$ ls /home/vmuser/test/bin
activate       activate_this.py  pip     python3
activate.csh   activate.xsh      pip3    python3.6
activate.fish  easy_install      pip3.6  python-config
activate.ps1   easy_install-3.6  python  wheel

Als Problemumgehung können Sie python -m lib2to3 in Ihrer virtuellen Umgebung mit gleichwertiger Funktionalität verwenden.

/cc andere @pypa/virtualenv-Committer, wenn sie der Meinung sind, dass es eine gute Idee ist, Skripte aus der Standardbibliothek der virtuellen Umgebung hinzuzufügen, wenn sie sie erstellen.

Ich bin ambivalent.

Ich bin -0,5. Es ist zusätzliche Unordnung, die bisher nicht als Problem gekennzeichnet wurde, daher gehe ich davon aus, dass die Notwendigkeit selten ist. Ich bin nicht davon überzeugt, dass Python 2, das sich EOL nähert, hier einen Unterschied macht. Die zusätzlichen Skripte befinden sich auch nicht auf PATH in einer nicht-virtuellen Umgebung unter Windows, daher ist es nicht so, dass die Erwartung, dass sie vorhanden sind, universell ist.

Ich denke, das sollte als allgemeiner Ansatz funktionieren. Alle Anwendungen in der Hostumgebung sollten auf der Ebene der virtuellen Umgebung verfügbar sein.

Ich bin nicht davon überzeugt, dass Python 2, das sich EOL nähert, hier einen Unterschied macht.

+1

Darum geht es mir hier auch nicht. :)

Die zusätzlichen Skripte befinden sich auch nicht auf PATH in einer nicht virtuellen Umgebung unter Windows

Oh. Sind diese nicht im Verzeichnis Scripts/ ? Mein Verständnis war, dass die aktuellen python.org-Installationsprogramme dieses Verzeichnis zu PATH hinzufügen und somit ausgeführt werden können.

Alle Anwendungen in der Hostumgebung sollten auf der Ebene der virtuellen Umgebung verfügbar sein.

Ähm ... "Anwendungen" ist hier etwas vage - beziehen Sie sich auf die Skripte oder etwas anderes? Könnten Sie bitte klarstellen, was Sie meinen?

Beachten Sie, dass ich, wenn wir dies tun, eine starke -1 bin, wenn es darum geht, alle Skripte aus der Hostumgebung einzuschließen, und ambivalent, wenn es darum geht, diejenigen einzuschließen, die von der Standardbibliothek unterstützt werden.

Oh. Sind diese nicht im Verzeichnis Scripts/?

Nein, alles, was in Scripts enthalten ist, sind Einstiegspunkt-Wrapper für installierte Bibliotheken (pip, easy_install und wheel in einer Basisinstallation). Wenn Sie etwas weiter schauen, befindet sich 2to3.py in Tools/scripts (zusammen mit einer ziemlich gemischten Gruppe von über 60 anderen Skripten), aber dieses Verzeichnis befindet sich nicht in PATH , selbst wenn der Benutzer wählt "Python zu Ihrem PATH hinzufügen" aus.

Beachten Sie, dass ich, wenn wir dies tun, eine starke -1 bin, wenn es darum geht, alle Skripte aus der Hostumgebung einzuschließen, und ambivalent, wenn es darum geht, diejenigen einzuschließen, die von der Standardbibliothek unterstützt werden.

Zumindest würde ich argumentieren, dass wir PATH nicht mehr hinzufügen sollten als eine einfache Installation. Das heißt, selbst wenn wir das tun, tun wir es nicht unter Windows.

pradyunsg hat vor 2 Stunden den Titel Include Standard Library scripts in virtualenv's bin/ Include Standard Library scripts in virtualenv's scripts geändert

Ich bemerke nur, dass dies eine geringfügige Änderung des Umfangs ist. Das OP war nur speziell an 2to3 interessiert, und insbesondere daran, dass die Aktivierung einer virtuellen Umgebung das System 2to3 nicht beschattet hat. Ob das wichtig ist, kann ich nicht kommentieren (da ich argumentiert habe, dass dies unter Windows nicht passiert, habe ich keine relevanten Erfahrungen mit Unix, um zu sagen, ob ich das Gefühl habe, dass dies ein Problem ist). Aber ohne zu wissen, welche anderen Skripte "Standardbibliotheksskripte" sind, kann ich nicht kommentieren, ob dies ein wichtiger Punkt ist.

Hmm, pyvenv ist wahrscheinlich ein weiteres "Standardbibliotheksskript", und ich bin mir ziemlich sicher, dass wir die Systemversion davon nicht mit einer schattieren wollen, die venv aus einer virtualenv-Umgebung ausführt (da dies nur zu Komplikationen führt ohne praktischen Nutzen).

Das OP war ... interessiert ... insbesondere daran, dass die Aktivierung einer virtuellen Umgebung das System nicht 2to3 beschattet hat.

(Ich bin mir nicht sicher, was dieser Satz in meinen Mund bringt, er könnte in beide Richtungen interpretiert werden.)

Aus Gründen der Klarheit bitte ich um virtualenv , um ein Shim für 2to3 $ zu erstellen.

(Lassen Sie mich den ursprünglichen Beitrag mit dem erwarteten Verhalten bearbeiten. Ich sehe, dass das Weglassen Verwirrung stiftet.)

(Lassen Sie mich den ursprünglichen Beitrag mit dem erwarteten Verhalten bearbeiten)

Getan. Ich habe auch klargestellt, warum der Benutzer erwartet hat, dass es auf PATH steht.

Ich bin mir nicht sicher, was dieser Satz in meinem Mund bringt

Entschuldigung für die falsche Darstellung Ihrer Kommentare und danke für die Klarstellung! (Es sieht so aus, als hätte ich richtig verstanden, wonach Sie gefragt haben, ich habe es nur schlecht wiederholt ...)

Ich habe auch klargestellt, warum der Benutzer erwartet hat, dass es auf PATH ist.

Der Link, auf den Sie verwiesen haben, ist etwas verwirrend. Der Benutzer scheint einen Prozess zu haben, der auf Trusty und Xenial funktioniert, aber nicht auf Bionic. Es ist mir nicht klar, warum das der Fall wäre, wenn das Problem in virtualenv liegt. (Hinweis: Dies ist ein Exkurs - unabhängig davon ist es eindeutig der Fall, dass virtualenv 2to3.py nicht kopiert, daher ist die Diskussion darüber, ob wir dies tun sollten, gültig, auch wenn das ursprüngliche Problem subtiler ist).

Ich bitte Virtualenv, ein Shim für 2to3 zu erstellen.

Beachten Sie, dass wir niemals ein Shim erstellen werden. Alles, was wir tun würden, ist das Skript 2to3.py zu kopieren. Wenn ein Shim benötigt wird (das ist eine Pyvenv-Sache, denke ich), dann würden wir uns nicht darum kümmern.

Nein, alles, was in Scripts enthalten ist, sind Einstiegspunkt-Wrapper für installierte Bibliotheken (pip, easy_install und wheel in einer Basisinstallation).

Ooooooooooooo. In Ordnung.

Ich bemerke nur, dass dies eine geringfügige Änderung des Umfangs ist.

Ich glaube nicht, dass 2to3 eine besondere Schneeflocke ist – wenn wir das hinzufügen, erwarte ich, dass jemand vorbeikommt und nach dem Rest fragt. Wir sollten dies entweder vollständig tun oder gar nicht. Auf halbem Weg stecken zu bleiben ist nichts, was wir hier wollen.

(Ich hasse die mobile Benutzeroberfläche)

Es ist insofern "besonders", als es von der Standardbibliothek unterstützt wird UND sich für eine Standard-Linux-Installation in PATH befindet.
Es gibt nicht viele andere Tools wie dieses. Außer 2to3 sind es nur pydoc , idle und pyvenv :

$ ls ~/.pyenv/versions/3.6.9/bin
2to3          easy_install-3.6  idle3.6  pip3.6  pydoc3.6  python3.6         python3.6m         python-config  virtualenv
2to3-3.6      idle              pip      pydoc   python    python3.6-config  python3.6m-config  pyvenv
easy_install  idle3             pip3     pydoc3  python3   python3.6-gdb.py  python3-config     pyvenv-3.6

(auch python-config was bereits umgeleitet wird)

Ah, danke für die Klarstellung @native-api! Sehr geschätzt. Zusammen mit der Erklärung von @pfmoore , dass dies ein Nicht-Windows-Problem ist, hilft mir das beim Verständnis. :)

Ich bin immer noch ambivalent, es aufzunehmen.

Außer 2to3 sind es nur pydoc, im Leerlauf und pyvenv

Mich würde interessieren, wer diese Liste ausgewählt hat. Ist es speziell pyvenv? Ubuntu (Bash unter Windows und ein Docker-Image mit installiertem Python3) scheint standardmäßig kein 2to3 zu haben, obwohl das Python-Docker-Image die gleichen Binärdateien enthält, die Sie erwähnt haben (plus pip, easy_install und wheel, die aus installierten Paketen stammen). Es scheint ein bisschen von der Distribution abhängig zu sein :-( Zumindest die Liste der relevanten Binärdateien scheint jedoch konsistent zu sein.

Übrigens, wie ich oben sagte, rate ich dringend davon ab, pyvenv einzubeziehen, selbst wenn wir diese Änderung vornehmen.

Ubuntu (Bash unter Windows und ein Docker-Image mit installiertem Python3) scheint standardmäßig kein 2to3 zu haben

Das liegt daran, dass 2to3 in Ubuntu in ein separates Paket verschoben wird:

$ apt-file search 2to3 | grep -E '/2to3[^/]*$'
2to3: /usr/bin/2to3
<...>
python2.7: /usr/bin/2to3-2.7
<...>

Mit "Standard-Linux-Installation" meinte ich die Logik, die Pythons Linux-Build-Skript ohne Einmischung von Distributionen innewohnt -- zB wenn Sie von der Quelle installieren (was pyenv tut).

Ich könnte das aufgreifen und werde versuchen, daran zu arbeiten.

Beachten Sie, dass dies unseren aktuellen Hack zum Hinzufügen von Pydoc als Teil des Aktivierungsskripts ersetzen würde.