Tentei instalar o python, pip e virtualenv pela primeira vez hoje e enfrentei o mesmo problema.

Eu consertei comentando 3 linhas em
Python\Python37\Lib\site-packages\virtualenv.py
e adicionando
-p python
ao executar o virtualenv

As linhas que comentei são 783-785:
if hasattr(sys, "_base_executable"):
print("hasattr(sys, \"_base_executable\") == yes")
return sys._base_executable

@AndrYast depois de ativar o ambiente você ainda está no 3.7.4? Isso definitivamente parece ser um problema específico com 3.7.4, que foi lançado ontem (7/8/19).

@thingselliotprograms yes, running
venv\Scripts\activate
python --version
me dá
Python 3.7.4

Enfrentando o mesmo problema com pipenv suspenso desde a atualização do python ontem para 3.7.4. Questão subjacente relacionada ao virtualenv. Python rebaixado para 3.7.3 por enquanto.

Ack virtualenv mais recente está quebrado porque https://github.com/python/cpython/pull/14428 sempre define sys._base_executable .

Estou tendo o mesmo problema com 3.7.4. Estou usando pipenv e recebendo [WinError 8] Not enough memory resources are available to process this command . Não consigo criar nenhum virtualenv. Tudo funciona bem no 3.7.3.

Também estou enfrentando esse mesmo problema com o 3.7.4.

A enxurrada de processos python.exe esgota a memória e a criação do virtualenv acaba falhando.

O problema não existia com 3.7.2.

Mantenedor aqui. Como eu disse acima, o contrato para alguma variável interna do CPython mudou, e isso agora causa um loop infinito na criação do processo para python 3.7 e 3.8.

Não tenho ideia se isso é uma _boa_ ideia, mas fui capaz de criar um ambiente virtual com este hack rápido.

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

A julgar pelos comentários acima dessa linha, parece que você se divertiu um pouco na versão anterior.

Talvez seja necessária uma verificação adicional de sys._base_executable != sys.executable . Mas, honestamente, eu não sei - isso parece estar mudando continuamente nos lançamentos de patch e eu não tenho tempo para acompanhar o que está acontecendo (tudo parece estar relacionado ao trabalho de suporte à compilação da "Windows Store" de Python).

Talvez @zooba possa comentar ou oferecer sugestões aqui. Estamos usando dados internos não documentados, então, em última análise, cabe a nós resolver o problema, mas não conheço uma maneira de obter as informações de que precisamos, então não vejo uma solução que não esteja sujeita a potencial quebra cada vez que obtemos uma nova versão do Python :-(

Em última análise, # 1377 é provavelmente a única solução confiável aqui.

Acho que, enquanto adicionarmos esse cheque, estaremos bem.

Os trabalhos do Travis CI executando o Windows e tentando criar um virtualenv também falham. Travis CI mudou recentemente para 3.7.4. 😞

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

Informações possivelmente úteis das compilações do 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

Acho que, enquanto adicionarmos esse cheque, estaremos bem.

Isso não irá reintroduzir (no 3.7.4) os problemas que a verificação base_executable pretendia corrigir? É certo que esses problemas eram muito menos sérios, então provavelmente ainda vale a pena fazer isso, mas não acho que seja uma solução completa.

Não acho que causa regressão, pois não?

Não testei de uma forma ou de outra (e não terei tempo para, desculpe).

Qual é a conclusão aqui, é possível uma versão de correção para o virtualenv?

Sim, se alguém fizer uma RP com a correção 😊

Você tem um teste para a regressão que mencionou?

Eu acho que sim.

O teste relevante (adicionado em # 1345) é test_create_environment_from_venv - mas observe que ele precisa ser executado em todos os Python 3.7.2, 3.7.3 e 3.7.4, pois o comportamento é diferente em cada um deles ( versões secundárias), e isso não é algo que o IC abrangerá, pelo que eu sei.

Obrigado pelas correções rápidas em torno de pessoal, acredito que comparar base_executable com executable fornece um equivalente funcional a simplesmente verificar a presença do atributo _base_executable (possivelmente é ainda mais seguro, pois é um pouco mais explícito)

Estou curioso para saber o que causou o problema em primeiro lugar.

Você precisa obter o sistema python para criar um ambiente virtual. Tentar criar um ambiente virtual com um pacote venv ou virtualenv não funcionará.

Anteriormente, sys._base_executable era definido no python 3.7+ apenas se não estivéssemos no sistema python. Isso mudou com o PR acima para sempre definido (se o Python não pertencente ao sistema será igual a sys.executable ). A mudança simplifica o código integrado para CPython (na parte da biblioteca padrão do sistema e descoberta de pacote do site), daí a mudança, mas é uma mudança de contrato. Dito isso, por ser um atributo privado, a alteração não foi considerada inválida, então está tudo bem. Então, novamente, não poderíamos obter essas informações de outro lugar, então estávamos contando com este campo privado.

Python 3.7.4
Tendo o mesmo problema, postando nossa saída caso seja ú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 criado. Eu recomendo fortemente alguns testes manuais antes da fusão. Não tenho o 3.7.4 instalado, então não testei a mudança e não sei qual versão secundária do 3.7 CI está em execução no momento.

Talvez algumas das pessoas que relatam o problema aqui possam testar a alteração e confirmar se ela corrige o problema e não apresenta nenhuma outra falha.

Funciona com Python 3.7.4 no Travis CI! Não vejo novos problemas.

Esta é a configuração do Travis que usei para o teste (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

Os 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 com Python 3.7.4 no Travis CI! Não vejo novos problemas.

Excelente, obrigado por confirmar

os: windows

Eu não sabia que o Travis oferecia ambientes Windows agora, isso é interessante :-)

@pfmoore Eles enfatizam que o Windows é de "acesso antecipado" e tem problemas (significativamente, você não pode usar segredos).

Sim, o suporte do Windows foi implementado pouco antes de as coisas do #travisAlums acontecerem IIRC (a nova empresa controladora reduziu drasticamente a equipe de Travis)

Eu tenho este código (no arquivo virtualenv.py) para corrigi-lo:
origem é:
if hasattr (sys, "_base_executable"):
e alterado para:
if hasattr (sys, "_base_executable") e não os.environ.get ("VIRTUALENV_INTERPRETER_RUNNING"):
fazendo isso, consertaria o loop

A correção deve ser lançada via https://pypi.org/project/virtualenv/16.6.2/

Acabei de testar e está de fato corrigido. Muito obrigado pelas respostas rápidas e boas.