Es stellt sich heraus, dass python -m pip "funktioniert", installiert jedoch Pakete in der ursprünglichen virtuellen Umgebung.

(outer) [vagrant@vagrant-arch ~]$ deactivate 
[vagrant@vagrant-arch ~]$ source virtualenv/bin/activate
(virtualenv) [vagrant@vagrant-arch ~]$ python -m pip install tox

Ist das aktive venv, sollte tox enthalten

(virtualenv) [vagrant@vagrant-arch ~]$ ls virtualenv/lib/python3.6/site-packages/
(virtualenv) [vagrant@vagrant-arch ~]$ ls virtualenv/bin/
activate  activate.csh  activate.fish  python  python3

Aber tox wird auf der ursprünglichen virtuellen Umgebung installiert

(virtualenv) [vagrant@vagrant-arch ~]$ ls outer/lib/python3.6/site-packages/
__pycache__      pip                  pkg_resources  pluggy-0.5.2.dist-info  py-1.4.34.dist-info  setuptools-36.6.0.dist-info  six.py  tox-2.9.1.dist-info          virtualenv.py       wheel
easy_install.py  pip-9.0.1.dist-info  pluggy         py                      setuptools           six-1.11.0.dist-info         tox     virtualenv-15.1.0.dist-info  virtualenv_support  wheel-0.30.0.dist-info
(virtualenv) [vagrant@vagrant-arch ~]$ ls outer/bin 
activate  activate.csh  activate.fish  activate_this.py  easy_install  easy_install-3.6  pip  pip3  pip3.6  python  python-config  python3  python3.6  tox  tox-quickstart  virtualenv  wheel

Ich habe versucht, ein ähnliches Venv mit der Option --copies erstellen, aber es hatte keine Auswirkung.

Treffen Sie dies auch hier: https://github.com/pre-commit/pre-commit/issues/755

Ich vermute, dass von der Seite venv ein Fix benötigt wird, um den Tanz .real_prefix . Ich werde diesen Ansatz als Workaround für pre-commit

Dies scheint das bpo-Problem zu sein: https://bugs.python.org/issue30811

Ich vermute, dass von der Venv-Seite ein Fix benötigt wird, um den .real_prefix -Tanz zu machen.

Mir ist nicht klar, wer für das Update verantwortlich sein soll. Sollte venv erkennen, dass es innerhalb von virtualenv , oder sollte virtualenv eine Umgebung erstellen, die mit venv kompatibel ist? Einerseits ist virtualenv älter als venv . Auf der anderen Seite ist venv Teil der Standardbibliothek.

Unabhängig davon, hier ist die Problemumgehung, die ich derzeit in tox-venv habe:

https://github.com/tox-dev/tox-venv/blob/58401663fda66dfba4f344553525c73d57432d5e/src/tox_venv/hooks.py#L10 -L49

Die Erkennung ausführbarer Pfade könnte verbessert werden, da derzeit nur nach python3 . Beispiel: Sie möchten vielleicht python3.6 , aber python3 zeigt auf python3.4 .

Ich habe mich für eine ähnliche Problemumgehung entschieden: https://github.com/pre-commit/pre-commit/blob/805a2921ad0d34698433972c6fcb1a6dca47191d/pre_commit/languages/python_venv.py#L13 -L39

(Der Hauptunterschied besteht darin, dass das Pre-Commit bereits einige Normalisierungen durchführt, sodass ich bin/$(basename exe) anstelle von nur bin/python3 )

Eh, ja, insgesamt denke ich, wir sollten venv-kompatibel sein.

@gaborbernat Laut berdario / pew # 173 scheint das nicht der Fall zu sein. @uranusjr Möchtest du mitmachen ?

Dieses Problem wurde automatisch als veraltet markiert, da es in letzter Zeit keine Aktivitäten gab. Es wird geschlossen, wenn keine weitere Aktivität stattfindet. Fügen Sie einfach einen Kommentar hinzu, wenn Sie ihn offen halten möchten. Vielen Dank für Ihre Beiträge.

1343

@gaborbernat Ich denke, das Problem sollte in "Ausführen von venv in virtualenv" umbenannt werden, um es von # 1339 zu unterscheiden.

@FranklinYu ist der aktualisierte Titel ausreichend?

Dies wird obsolet, da # 1366 jetzt in vollem Gange ist.