Сегодня я впервые попытался установить python, pip и virtualenv и столкнулся с той же проблемой.

Я исправил это, прокомментировав 3 строки в
Python\Python37\Lib\site-packages\virtualenv.py
и добавление
-p python
при запуске virtualenv

Я прокомментировал строки 783-785:
if hasattr(sys, "_base_executable"):
print("hasattr(sys, \"_base_executable\") == yes")
return sys._base_executable

@AndrYast после активации окружения все еще на 3.7.4? Это определенно похоже на проблему с версией 3.7.4, которая была выпущена вчера (8.07.19).

@thingselliotprograms да, работает
venv\Scripts\activate
python --version
дает мне
Python 3.7.4

Возникла та же проблема с зависанием pipenv после вчерашнего обновления python до 3.7.4. Основная проблема, связанная с virtualenv. Python понижен до версии 3.7.3.

Ack virtualenv latest не работает, потому что https://github.com/python/cpython/pull/14428 всегда устанавливает sys._base_executable .

У меня такая же проблема с 3.7.4. Я использую pipenv и получаю [WinError 8] Not enough memory resources are available to process this command . Я не могу создавать виртуальных машин. В 3.7.3 все отлично работает.

У меня тоже возникла эта проблема с версией 3.7.4.

Грохот процессов python.exe истощает память, и создание virtualenv в конечном итоге терпит неудачу.

Проблема не существовала с 3.7.2.

Сопровождающий здесь. Как я уже сказал выше, контракт для некоторой внутренней переменной CPython изменился, и теперь это вызывает бесконечный цикл при создании процесса как для python 3.7, так и для 3.8.

Не знаю, хорошая ли это идея, но мне удалось создать виртуальную среду с помощью этого быстрого взлома.

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

Судя по комментариям над этой строкой, похоже, вы немного повеселились в более ранней версии.

Возможно, нужна дополнительная проверка того, что sys._base_executable != sys.executable . Но, честно говоря, я не знаю - похоже, что это постоянно меняется в выпусках патчей, и у меня нет времени следить за тем, что происходит (похоже, все это связано с работой по поддержке сборки "Windows Store" Python).

Возможно, @zooba может здесь прокомментировать или предложить предложения. Мы используем недокументированные внутренние компоненты, поэтому в конечном итоге проблема остается за нами, но я не знаю поддерживаемого способа получения необходимой нам информации, поэтому я не вижу решения, которое не подлежало бы потенциальная поломка каждый раз, когда мы получаем новую версию Python :-(

В конечном счете, №1377, вероятно, является единственным надежным решением здесь.

Думаю, пока мы добавим этот чек, все будет в порядке.

Задания Travis CI под управлением Windows и попытки создать виртуальный сервер также терпят неудачу. Travis CI недавно перешел на 3.7.4. 😞

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

Возможно полезная информация из сборок Трэвиса:

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

Думаю, пока мы добавим этот чек, все будет в порядке.

Разве это не приведет к повторному появлению (в 3.7.4) проблем, которые должна была исправить проверка base_executable? По общему признанию, эти проблемы были гораздо менее серьезными, поэтому, вероятно, все же стоит заняться, но я не думаю, что это полное решение.

Я не думаю, что это вызывает регресс, не так ли?

Я так или иначе не тестировал (и не успею, извините).

Каков вывод, возможен ли выпуск исправления для virtualenv?

Да, если кто-то устроит пиар с исправлением 😊

У вас есть тест на регрессию, о которой вы упомянули?

Я думаю, что да.

Соответствующий тест (добавлен в # 1345) - это test_create_environment_from_venv но обратите внимание, что его нужно запускать во всех Python 3.7.2, 3.7.3 и 3.7.4, поскольку поведение в каждом из них отличается ( второстепенные) версии, и, насколько мне известно, это не то, что CI будет покрывать.

Спасибо за быстрые исправления всем, я считаю, что сравнение base_executable с executable обеспечивает функциональный эквивалент простой проверки наличия атрибута _base_executable (возможно, это даже безопаснее, чем это немного более ясно)

Мне любопытно, что вообще вызвало проблему.

Вам нужно получить системный питон для создания виртуальной среды. Попытка создать виртуальную среду с помощью пакета venv или virtualenv не сработает.

Ранее sys._base_executable был установлен на python 3.7+ только в том случае, если мы не были в системном python. Это изменилось с указанным выше PR, чтобы он всегда устанавливался (если не системный Python будет равен sys.executable ). Это изменение упрощает встроенный код для CPython (в части стандартной системной библиотеки и обнаружения пакетов сайта), отсюда и изменение, но это изменение контракта. При этом, учитывая, что это частный атрибут, изменение не считалось нарушением, так что все в порядке. Опять же, мы не могли получить эту информацию из другого места, поэтому мы полагались на это частное поле.

Python 3.7.4
Имея ту же проблему, опубликуйте наш результат на случай, если он будет полезен:

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 года. Я настоятельно рекомендую выполнить ручное тестирование перед слиянием. У меня не установлена ​​версия 3.7.4, поэтому я вообще не тестировал изменения и не знаю, какая младшая версия 3.7 CI работает в настоящее время.

Может быть, некоторые из людей, сообщающих о проблеме здесь, могут протестировать изменение и подтвердить, что оно устраняет их проблему и не приводит к другим поломкам?

Он работает с Python 3.7.4 на Travis CI! Не вижу новых проблем.

Это конфигурация Travis, которую я использовал для теста (соответствующая часть):

    - 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

Результаты (соответствующие части):

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

Он работает с Python 3.7.4 на Travis CI! Не вижу новых проблем.

Отлично, спасибо за подтверждение

os: windows

Я не понимал, что Трэвис сейчас предоставляет среды Windows, это интересно :-)

@pfmoore Они подчеркивают, что Windows является «ранним доступом» и имеет проблемы (что особенно важно, вы не можете использовать секреты).

Да, поддержка Windows была развернута незадолго до того, как произошли события #travisAlums IIRC (новая материнская компания резко сократила команду Трэвиса)

У меня есть этот код (в файле virtualenv.py), чтобы исправить это:
происхождение:
если hasattr (sys, "_base_executable"):
и изменился на:
если hasattr (sys, "_base_executable"), а не os.environ.get ("VIRTUALENV_INTERPRETER_RUNNING"):
сделав это, исправит петлю

Исправление должно быть выпущено через https://pypi.org/project/virtualenv/16.6.2/.

Только что протестировано, и это действительно исправлено. Большое спасибо за быстрые и хорошие ответы.