Ich habe heute zum ersten Mal versucht, Python, Pip und Virtualenv zu installieren und stand vor dem gleichen Problem.

Ich habe es behoben, indem ich 3 Zeilen kommentiert habe
Python\Python37\Lib\site-packages\virtualenv.py
und hinzufügen
-p python
beim Ausführen von virtualenv

Die Zeilen, die ich kommentiert habe, sind 783-785:
if hasattr(sys, "_base_executable"):
print("hasattr(sys, \"_base_executable\") == yes")
return sys._base_executable

@AndrYast bist du nach dem Aktivieren der Umgebung immer noch auf 3.7.4? Dies scheint definitiv ein Problem speziell mit 3.7.4 zu sein, das gestern (7.08.19) veröffentlicht wurde.

@thingselliotprograms ja, läuft
venv\Scripts\activate
python --version
gibt mir
Python 3.7.4

Das gleiche Problem mit dem Hängen von Pipenv seit dem gestrigen Upgrade von Python auf 3.7.4. Zugrundeliegendes Problem im Zusammenhang mit virtualenv. Python wurde vorerst auf 3.7.3 herabgestuft.

Ack virtualenv Latest ist defekt, weil https://github.com/python/cpython/pull/14428 immer sys._base_executable .

Ich habe das gleiche Problem mit 3.7.4. Ich verwende pipenv und bekomme ein [WinError 8] Not enough memory resources are available to process this command . Ich kann keine Virtualenv erstellen. In 3.7.3 funktioniert alles super.

Ich habe genau dieses Problem auch mit 3.7.4.

Das Donnern von python.exe-Prozessen erschöpft den Speicher und die Erstellung von Virtualenv schlägt letztendlich fehl.

Das Problem bestand nicht mit 3.7.2.

Betreuer hier. Wie ich oben sagte, hat sich der Vertrag für einige interne Variablen von CPython geändert, und dies führt nun zu einer Endlosschleife bei der Prozesserstellung sowohl für Python 3.7 als auch für 3.8.

Keine Ahnung, ob das eine _gute_ Idee ist, aber ich konnte mit diesem schnellen Hack eine virtuelle Umgebung erstellen.

# virtualenv.py:783
if hasattr(sys, "_base_executable") and sys.version_info < (3, 7, 4):
    return sys._base_executable

Den Kommentaren über dieser Zeile nach zu urteilen, sieht es so aus, als ob Sie in einer früheren Version etwas Spaß hatten.

Vielleicht muss zusätzlich geprüft werden, ob sys._base_executable != sys.executable . Aber ehrlich gesagt, ich weiß es nicht - dies scheint sich in den Patch-Releases ständig zu ändern und ich habe nicht die Zeit, mit dem, was vor sich geht, Schritt zu halten (alles scheint mit der Arbeit zur Unterstützung des "Windows Store" -Builds zu tun zu haben von Python).

Vielleicht könnte @zooba hier Kommentare die nicht Gegenstand von potenzieller Bruch jedes Mal, wenn wir eine neue Version von Python erhalten :-(

Letztendlich ist #1377 hier wohl die einzig zuverlässige Lösung.

Ich denke, solange wir diesen Scheck hinzufügen, wird es uns gut gehen.

Travis CI-Jobs, die Windows ausführen und versuchen, eine virtuelle Umgebung zu erstellen, schlagen ebenfalls fehl. Travis CI ist kürzlich auf 3.7.4 umgezogen. 😞

https://travis-ci.community/t/infinite-loop-of-virtualenv-windows/4139

Möglicherweise hilfreiche Informationen aus den Travis-Builds:

version: v6.2.0 https://github.com/travis-ci/worker/tree/5e5476e01646095f48eec13196fdb3faf8f5cbf7
instance: travis-ci-onion-1803-containers-1542208204-ad01dca (via amqp)
bash version 4.4.19(2)-release
Chocolatey v0.10.11
python3 v3.7.4 [Approved]
python3 has been installed.
Successfully installed pip-19.1.1
Successfully installed virtualenv-16.6.1

$ virtualenv $HOME/venv
Running virtualenv with interpreter c:\python37\python.exe
Running virtualenv with interpreter c:\python37\python.exe
Running virtualenv with interpreter c:\python37\python.exe
Running virtualenv with interpreter c:\python37\python.exe
Running virtualenv with interpreter c:\python37\python.exe
...[repeats 763 more times]...
The command "virtualenv $HOME/venv" failed and exited with 1 during .
Your build has been stopped.
MemoryError

Ich denke, solange wir diesen Scheck hinzufügen, wird es uns gut gehen.

Werden die Probleme, die die base_executable-Prüfung beheben sollte, nicht wieder eingeführt (in 3.7.4)? Zugegeben, diese Probleme waren weitaus weniger schwerwiegend, daher lohnt es sich wahrscheinlich immer noch, es zu tun, aber ich glaube nicht, dass es eine vollständige Lösung ist.

Ich glaube nicht, dass es eine Regression verursacht, oder?

Ich habe es nicht auf die eine oder andere Weise getestet (und werde keine Zeit dazu haben, sorry).

Was ist hier das Fazit, ist ein Fix-Release für virtualenv möglich?

Ja, wenn jemand eine PR mit dem Fix macht 😊

Haben Sie einen Test für die von Ihnen erwähnte Regression?

Ich denke, das tun wir.

Der relevante Test (hinzugefügt in #1345) ist test_create_environment_from_venv - aber beachten Sie, dass er in allen Python 3.7.2, 3.7.3 und 3.7.4 ausgeführt werden muss, da das Verhalten in jedem von diesen unterschiedlich ist ( Minor) Versionen, und das ist nichts, was die CI abdecken wird, soweit ich weiß.

Vielen Dank für die schnellen Korrekturen, Leute, ich glaube, der Vergleich von base_executable mit executable bietet ein funktionales Äquivalent zum einfachen Prüfen auf das Vorhandensein des _base_executable Attributs (möglicherweise ist es sogar noch sicherer als es ist etwas expliziter)

Ich bin jedoch gespannt, was das Problem überhaupt verursacht hat.

Sie müssen die Systempython erhalten, um eine virtuelle Umgebung zu erstellen. Der Versuch, eine virtuelle Umgebung mit einem venv- oder einem virtualenv-Paket zu erstellen, funktioniert nicht.

Zuvor wurde sys._base_executable auf Python 3.7+ nur gesetzt, wenn wir nicht in Systempython waren. Dies änderte sich mit dem obigen PR zu immer gesetzt (wenn Nicht-System-Python gleich sys.executable ). Die Änderung vereinfacht den eingebauten Code für CPython (im Teil der Systemstandardbibliothek und Site Package Discovery), daher die Änderung, aber es handelt sich um eine Vertragsänderung. Angesichts der Tatsache, dass es sich um ein privates Attribut handelt, wurde die Änderung jedoch nicht als gebrochen angesehen, also ist es in Ordnung. Andererseits konnten wir diese Informationen nicht von einem anderen Ort beziehen, also verließen wir uns auf dieses private Feld.

Python 3.7.4
Habe das gleiche Problem und poste unsere Ausgabe, falls es hilfreich ist:

Requirement already up-to-date: virtualenv in c:\users\tester\appdata\local\programs\python\python37\lib\site-packages (16.6.1)
Running virtualenv with interpreter c:\users\tester\appdata\local\programs\python\python37\python.exe
Running virtualenv with interpreter c:\users\tester\appdata\local\programs\python\python37\python.exe
Running virtualenv with interpreter c:\users\tester\appdata\local\programs\python\python37\python.exe
...
(Repeated 350 times in total)

Traceback (most recent call last):
  File "c:\users\tester\appdata\local\programs\python\python37\lib\site-packages\virtualenv.py", line 2611, in <module>
    main()
  File "c:\users\tester\appdata\local\programs\python\python37\lib\site-packages\virtualenv.py", line 814, in main
    sub_process_call = subprocess.Popen([interpreter, file] + sys.argv[1:], env=env)
  File "c:\users\tester\appdata\local\programs\python\python37\lib\subprocess.py", line 775, in __init__
    restore_signals, start_new_session)
  File "c:\users\tester\appdata\local\programs\python\python37\lib\subprocess.py", line 1178, in _execute_child
    startupinfo)
OSError: [WinError 8] Not enough memory resources are available to process this command

1383 erstellt. Ich würde dringend empfehlen, vor dem Zusammenführen einige manuelle Tests durchzuführen. Ich habe 3.7.4 nicht installiert, also habe ich die Änderung überhaupt nicht getestet, und ich weiß nicht, welche Nebenversion von 3.7 CI derzeit ausgeführt wird.

Vielleicht könnten einige der Leute, die das Problem hier melden, die Änderung testen und bestätigen, dass sie ihr Problem behebt und keine anderen Schäden verursacht?

Es funktioniert mit Python 3.7.4 auf Travis CI! Ich sehe keine neuen Probleme.

Dies ist die Travis-Konfiguration, die ich für den Test verwendet habe (relevanter Teil):

    - stage: test
      os: windows
      language: shell
      env: PATH=/c/Python37:/c/Python37/Scripts:$PATH
      before_install:
        - choco install python
        # python -m pip install virtualenv
        - pip install git+https://github.com/pypa/virtualenv
        - virtualenv $HOME/venv
        - source $HOME/venv/Scripts/activate

Die Ergebnisse (relevante Teile):

Progress: Downloading python 3.7.4... 100%
python3 v3.7.4 [Approved]
python3 package files install completed. Performing other installation steps.
Installing 64-bit python3...
python3 has been installed.
Installed to: 'C:\Python37'
...
16.31s$ pip install git+https://github.com/pypa/virtualenv
Collecting git+https://github.com/pypa/virtualenv
  Cloning https://github.com/pypa/virtualenv to c:\users\travis\appdata\local\temp\pip-req-build-ceb1gi36
  Installing build dependencies: started
  Installing build dependencies: finished with status 'done'
  Getting requirements to build wheel: started
  Getting requirements to build wheel: finished with status 'done'
    Preparing wheel metadata: started
    Preparing wheel metadata: finished with status 'done'
Building wheels for collected packages: virtualenv
  Building wheel for virtualenv (PEP 517): started
  Building wheel for virtualenv (PEP 517): finished with status 'done'
  Stored in directory: C:\Users\travis\AppData\Local\Temp\pip-ephem-wheel-cache-kx8oezso\wheels\8d\58\76\749812a30b0b5c5cdc1b327e343711660ee5ebf51cf56d2df5
Successfully built virtualenv
Installing collected packages: virtualenv
Successfully installed virtualenv-16.6.1
46.51s$ virtualenv $HOME/venv
Using base prefix 'c:\\python37'
New python executable in C:\Users\travis\venv\Scripts\python.exe
Installing setuptools, pip, wheel...
done.
0.16s$ source $HOME/venv/Scripts/activate

Es funktioniert mit Python 3.7.4 auf Travis CI! Ich sehe keine neuen Probleme.

Super, danke für die Bestätigung

os: windows

Ich hatte nicht bemerkt, dass Travis jetzt Windows-Umgebungen bereitstellt, das ist interessant :-)

@pfmoore Sie betonen, dass Windows "Early Access" ist und Probleme hat (bedeutsamerweise können Sie keine Geheimnisse verwenden).

Ja, Windows-Unterstützung wurde eingeführt, kurz bevor #travisAlums-Sachen passierten IIRC (die neue Muttergesellschaft hat Travis' Team drastisch verkleinert)

Ich habe diesen Code (in der Datei virtualenv.py), um das Problem zu beheben:
Herkunft ist:
if hasattr(sys, "_base_executable"):
und geändert zu:
if hasattr(sys, "_base_executable") und nicht os.environ.get("VIRTUALENV_INTERPRETER_RUNNING"):
damit würde die Schleife repariert

Fix sollte über https://pypi.org/project/virtualenv/16.6.2/ veröffentlicht werden

Gerade getestet und es ist tatsächlich behoben. Vielen Dank für die schnellen und guten Antworten.