Intenté instalar python, pip y virtualenv por primera vez hoy y enfrenté el mismo problema.

Lo he arreglado comentando 3 líneas en
Python\Python37\Lib\site-packages\virtualenv.py
y agregando
-p python
al ejecutar virtualenv

Las líneas que comenté son 783-785:
if hasattr(sys, "_base_executable"):
print("hasattr(sys, \"_base_executable\") == yes")
return sys._base_executable

@AndrYast después de activar el entorno, ¿todavía estás en 3.7.4? Esto definitivamente parece ser un problema específicamente con 3.7.4, que se lanzó ayer (8/7/19).

@thingselliotprograms sí, corriendo
venv\Scripts\activate
python --version
me da
Python 3.7.4

Experimentando el mismo problema con pipenv colgado desde que actualicé Python ayer a 3.7.4. Problema subyacente relacionado con virtualenv. Python degradado a 3.7.3 por ahora.

Ack virtualenv latest está roto porque https://github.com/python/cpython/pull/14428 siempre establece sys._base_executable .

Tengo el mismo problema con 3.7.4. Estoy usando pipenv y obtengo un [WinError 8] Not enough memory resources are available to process this command . No puedo crear virtualenv. Todo funciona muy bien en 3.7.3.

También estoy experimentando este problema exacto con 3.7.4.

El trueno continuo de los procesos de python.exe agota la memoria y la creación de virtualenv finalmente falla.

El problema no existía con 3.7.2.

Mantenedor aquí. Como dije anteriormente, el contrato para alguna variable interna de CPython cambió, y esto provoca ahora un bucle infinito en la creación de procesos tanto para Python 3.7 como 3.8.

No tengo idea de si esto es una buena idea, pero pude crear un entorno virtual con este truco rápido.

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

A juzgar por los comentarios sobre esa línea, parece que te divertiste un poco en una versión anterior.

Tal vez deba haber un cheque adicional que sys._base_executable != sys.executable . Pero, sinceramente, no lo sé: esto parece estar cambiando continuamente en las versiones de parches y no tengo tiempo para estar al día con lo que está sucediendo (todo parece estar relacionado con el trabajo para respaldar la compilación de la "Tienda Windows" de Python).

Quizás @zooba podría comentar u ofrecer sugerencias aquí. Estamos utilizando componentes internos indocumentados, por lo que, en última instancia, el problema depende de nosotros para abordarlo, pero no conozco una forma compatible de obtener la información que necesitamos, por lo que no veo una solución que no esté sujeta a rotura potencial cada vez que obtengamos una nueva versión de Python :-(

En última instancia, el # 1377 es probablemente la única solución confiable aquí.

Creo que mientras agreguemos ese cheque, estaremos bien.

Los trabajos de Travis CI que ejecutan Windows e intentan crear un virtualenv también fallan. Travis CI se movió recientemente a 3.7.4. 😞

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

Posiblemente información útil de las compilaciones de Travis:

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

Creo que mientras agreguemos ese cheque, estaremos bien.

¿Hacer eso no reintroducirá (en 3.7.4) los problemas que la verificación base_executable tenía la intención de solucionar? Es cierto que esos problemas eran mucho menos graves, por lo que es probable que valga la pena hacerlo, pero no creo que sea una solución completa.

No creo que cause regresión, ¿verdad?

No he probado de una forma u otra (y no tendré tiempo de hacerlo, lo siento).

¿Cuál es la conclusión aquí? ¿Es posible una versión corregida para virtualenv?

Sí, lo es si alguien hace un PR con la solución 😊

¿Tiene una prueba para la regresión que mencionó?

Creo que lo hacemos.

La prueba relevante (agregada en # 1345) es test_create_environment_from_venv , pero tenga en cuenta que debe ejecutarse en todos los Python 3.7.2, 3.7.3 y 3.7.4 ya que el comportamiento es diferente en cada uno de esos ( minor), y eso no es algo que cubrirá el CI, hasta donde yo sé.

Gracias por las soluciones rápidas, creo que comparar base_executable con executable proporciona un equivalente funcional a simplemente verificar la presencia del atributo _base_executable (posiblemente sea incluso más seguro ya que es un poco más explícito)

Sin embargo, tengo curiosidad por saber qué causó el problema en primer lugar.

Necesita obtener el python del sistema para crear un entorno virtual. Intentar crear un entorno virtual con un paquete venv o virtualenv no funcionará.

Anteriormente, sys._base_executable se configuraba en python 3.7+ solo si no estábamos en el sistema python. Esto cambió con el PR anterior para que siempre se establezca (si Python fuera del sistema será igual a sys.executable ). El cambio simplifica el código incorporado para CPython (en la parte de la biblioteca estándar del sistema y el descubrimiento de paquetes del sitio), de ahí el cambio, pero es un cambio de contrato. Dicho esto, dado que es un atributo privado, el cambio no se consideró roto, por lo que está bien. Por otra parte, no pudimos obtener esta información de otro lugar, por lo que confiamos en este campo privado.

Python 3.7.4
Teniendo el mismo problema, publicando nuestra salida en caso de que sea útil:

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 creado. Recomendaría encarecidamente algunas pruebas manuales antes de fusionar. No tengo 3.7.4 instalado, así que no he probado el cambio en absoluto, y no sé qué versión menor de 3.7 CI se está ejecutando actualmente.

¿Quizás algunas de las personas que informan el problema aquí podrían probar el cambio y confirmar que soluciona el problema y que no presenta ninguna otra falla?

¡Funciona con Python 3.7.4 en Travis CI! No veo problemas nuevos.

Esta es la configuración de Travis que utilicé para la prueba (parte relevante):

    - 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

Los resultados (partes relevantes):

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

¡Funciona con Python 3.7.4 en Travis CI! No veo problemas nuevos.

Excelente, gracias por confirmar

os: windows

No me había dado cuenta de que Travis proporcionaba entornos de Windows ahora, eso es interesante :-)

@pfmoore Enfatizan que Windows es de "acceso anticipado" y tiene problemas (significativamente, no se pueden usar secretos).

Sí, el soporte de Windows se implementó justo antes de que sucedieran las cosas de #travisAlums IIRC (la nueva empresa matriz redujo drásticamente el equipo de Travis)

Tengo este código (en el archivo virtualenv.py) para solucionarlo:
el origen es:
si hasattr (sys, "_base_executable"):
y cambiado a:
si hasattr (sys, "_base_executable") y no os.environ.get ("VIRTUALENV_INTERPRETER_RUNNING"):
al hacer esto, arreglaría el bucle

La corrección debe publicarse a través de https://pypi.org/project/virtualenv/16.6.2/

Recién probado y de hecho está arreglado. Muchas gracias por las rápidas y buenas respuestas.