J'ai essayé d'installer python, pip et virtualenv pour la première fois aujourd'hui et j'ai rencontré le même problème.

Je l'ai corrigé en commentant 3 lignes dans
Python\Python37\Lib\site-packages\virtualenv.py
et en ajoutant
-p python
lors de l'exécution de virtualenv

Les lignes que j'ai commentées sont 783-785 :
if hasattr(sys, "_base_executable"):
print("hasattr(sys, \"_base_executable\") == yes")
return sys._base_executable

@AndrYast après avoir activé l'environnement êtes-vous toujours sur 3.7.4 ? Cela semble définitivement être un problème avec la 3.7.4, qui a été publiée hier (7/8/19).

@thingselliotprograms oui, en cours d'exécution
venv\Scripts\activate
python --version
Donne moi
Python 3.7.4

Rencontre avec le même problème avec pipenv suspendu depuis la mise à niveau de python hier vers 3.7.4. Problème sous-jacent lié à virtualenv. Python rétrogradé à 3.7.3 pour le moment.

Ack virtualenv dernier est cassé car https://github.com/python/cpython/pull/14428 définit toujours sys._base_executable .

J'ai le même problème avec 3.7.4. J'utilise pipenv et j'obtiens un [WinError 8] Not enough memory resources are available to process this command . Je ne peux pas créer de virtualenv. Tout fonctionne très bien dans 3.7.3.

Je rencontre aussi exactement ce problème avec 3.7.4.

Le roulement du tonnerre des processus python.exe épuise la mémoire et la création de virtualenv échoue finalement.

Le problème n'existait pas avec 3.7.2.

Mainteneur ici. Comme je l'ai dit ci-dessus, le contrat pour une variable interne de CPython a changé, ce qui provoque désormais une boucle infinie lors de la création de processus pour Python 3.7 et 3.8.

Aucune idée si c'est une _bonne_ idée, mais j'ai pu créer un environnement virtuel avec ce hack rapide.

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

À en juger par les commentaires au-dessus de cette ligne, il semble que vous vous soyez amusé dans une version antérieure.

Peut-être qu'il doit y avoir un contrôle supplémentaire que sys._base_executable != sys.executable . Mais honnêtement, je ne sais pas - cela semble changer continuellement dans les versions de correctifs et je n'ai pas le temps de suivre ce qui se passe (tout semble être lié au travail pour prendre en charge la version "Windows Store" de Python).

Peut-être que @zooba pourrait commenter ou offrir des suggestions ici. Nous utilisons des internes non documentés, donc en fin de compte, le problème nous appartient, mais je ne connais pas de moyen pris en charge pour obtenir les informations dont nous avons besoin, donc je ne vois pas de solution qui ne soit

En fin de compte, #1377 est probablement la seule solution fiable ici.

Je pense que tant que nous ajoutons ce chèque, tout ira bien.

Les travaux Travis CI exécutant Windows et tentant de créer un virtualenv échouent également. Travis CI est récemment passé à 3.7.4. ??

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

Informations éventuellement utiles sur les versions 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

Je pense que tant que nous ajoutons ce chèque, tout ira bien.

Cela ne réintroduira-t-il pas (sur 3.7.4) les problèmes que le contrôle base_executable était censé résoudre ? Certes, ces problèmes étaient beaucoup moins graves, donc cela vaut probablement la peine d'être fait, mais je ne pense pas que ce soit une solution complète.

Je ne pense pas que cela provoque une régression, n'est-ce pas?

Je n'ai pas testé d'une manière ou d'une autre (et je n'aurai pas le temps de le faire, désolé).

Quelle est la conclusion ici, une version de correctif est-elle possible pour virtualenv ?

Oui c'est si quelqu'un fait un PR avec le correctif 😊

Avez-vous un test pour la régression que vous avez mentionnée?

Je pense que nous le faisons.

Le test pertinent (ajouté dans #1345) est test_create_environment_from_venv - mais notez qu'il doit être exécuté dans tous les Python 3.7.2, 3.7.3 et 3.7.4 car le comportement est différent dans chacun de ces ( minor) versions, et ce n'est pas quelque chose que le CI couvrira, pour autant que je sache.

Merci pour les solutions rapides tout autour, je pense que comparer base_executable avec executable fournit un équivalent fonctionnel à la simple vérification de la présence de l'attribut _base_executable (c'est peut-être encore plus sûr car c'est un peu plus explicite)

Je suis curieux de savoir ce qui a causé le problème en premier lieu cependant.

Vous devez obtenir le système python pour créer un environnement virtuel. Essayer de créer un environnement virtuel avec un package venv ou virtualenv ne fonctionnera pas.

Auparavant, sys._base_executable était défini sur python 3.7+ uniquement si nous n'étions pas dans le système python. Cela a changé avec le PR ci-dessus pour toujours définir (si Python non système sera égal à sys.executable ). Le changement simplifie le code intégré pour CPython (dans la partie de la bibliothèque standard du système et de la découverte du package de site), d'où le changement, mais c'est un changement de contrat. Cela étant dit, étant donné qu'il s'agit d'un attribut privé, le changement n'a pas été considéré comme une rupture, donc tout va bien. Là encore, nous ne pouvions pas obtenir ces informations d'un autre endroit, nous nous sommes donc appuyés sur ce domaine privé.

Python 3.7.4
Ayant le même problème, poster notre sortie au cas où cela serait utile:

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 créé. Je recommanderais fortement des tests manuels avant de fusionner. Je n'ai pas installé 3.7.4, donc je n'ai pas du tout testé le changement, et je ne sais pas quelle version mineure de 3.7 CI est actuellement en cours d'exécution.

Peut-être que certaines des personnes signalant le problème ici pourraient tester le changement et confirmer qu'il résout leur problème et n'introduit aucun autre problème ?

Cela fonctionne avec Python 3.7.4 sur Travis CI ! Je ne vois pas de nouveaux problèmes.

Voici la configuration Travis que j'ai utilisée pour le test (partie pertinente) :

    - 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

Les résultats (parties pertinentes) :

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

Cela fonctionne avec Python 3.7.4 sur Travis CI ! Je ne vois pas de nouveaux problèmes.

Excellent, merci de confirmer

os: windows

Je n'avais pas réalisé que Travis fournissait des environnements Windows maintenant, c'est intéressant :-)

@pfmoore Ils soulignent que Windows est un "accès anticipé" et a des problèmes (ce qui signifie que vous ne pouvez pas utiliser de secrets).

Oui, la prise en charge de Windows a été déployée juste avant que les choses #travisAlums ne se produisent IIRC (la nouvelle société mère a considérablement réduit l'équipe de Travis)

J'ai ce code (dans le fichier virtualenv.py) pour le corriger :
l'origine est :
if hasattr(sys, "_base_executable") :
et changé en :
si hasattr(sys, "_base_executable") et non os.environ.get("VIRTUALENV_INTERPRETER_RUNNING") :
en faisant cela, corrigerait la boucle

Le correctif devrait être publié via https://pypi.org/project/virtualenv/16.6.2/

Je viens de tester et c'est effectivement corrigé. Merci beaucoup pour les réponses rapides et bonnes.