Virtualenv: Rupture dans --always-copy - échoue avec : ImportError : aucun module nommé time

Je rencontre également ce problème, mais comme solution de contournement, vous pouvez ajouter no-setuptools pour ne pas installer pip dans votre virtualenv. Ce problème est lié à l'installation de pip/setuptools dans le nouveau virtualenv.

Mes informations de version :

• Fedora 19 x86_64,
• Installation système de Python 2.7.5
• virtualenv 1.11.4
• pépin 1.5.4

Voici la sortie détaillée complète en cas d'échec :

[vagrant<strong i="14">@localhost</strong> ~]$ virtualenv --always-copy --clear --verbose foobar
Do not need to delete foobar/lib/python2.7; already gone
Not deleting foobar/bin
Creating foobar/lib/python2.7
Cannot find file lib (bad symlink)
Symlinking Python bootstrap modules
  Copying to foobar/lib/python2.7/config
  Copying to foobar/lib/python2.7/lib-dynload
  Creating parent directories for foobar/lib64/python2.7
  Copying to foobar/lib64/python2.7/os.py
  Ignoring built-in bootstrap module: posix
  Copying to foobar/lib64/python2.7/posixpath.py
  Cannot import bootstrap module: nt
  Copying to foobar/lib64/python2.7/ntpath.py
  Copying to foobar/lib64/python2.7/genericpath.py
  Copying to foobar/lib64/python2.7/fnmatch.py
  Copying to foobar/lib64/python2.7/locale.py
  Copying to foobar/lib64/python2.7/encodings
  Copying to foobar/lib64/python2.7/codecs.py
  Copying to foobar/lib64/python2.7/stat.py
  Copying to foobar/lib64/python2.7/UserDict.py
  Creating parent directories for foobar/lib64/python2.7/lib-dynload
  Copying to foobar/lib64/python2.7/lib-dynload/readline.so
  Copying to foobar/lib64/python2.7/copy_reg.py
  Copying to foobar/lib64/python2.7/types.py
  Copying to foobar/lib64/python2.7/re.py
  Copying to foobar/lib64/python2.7/sre.py
  Copying to foobar/lib64/python2.7/sre_parse.py
  Copying to foobar/lib64/python2.7/sre_constants.py
  Copying to foobar/lib64/python2.7/sre_compile.py
  Copying to foobar/lib64/python2.7/lib-dynload/zlibmodule.so
  Copying to foobar/lib64/python2.7/warnings.py
  Copying to foobar/lib64/python2.7/linecache.py
  Copying to foobar/lib64/python2.7/_abcoll.py
  Copying to foobar/lib64/python2.7/abc.py
  Copying to foobar/lib64/python2.7/_weakrefset.py
Creating foobar/lib/python2.7/site-packages
Writing foobar/lib64/python2.7/site.py
Writing foobar/lib64/python2.7/orig-prefix.txt
Writing foobar/lib64/python2.7/no-global-site-packages.txt
Creating parent directories for foobar/include
Copying to foobar/include/python2.7
Creating foobar/bin
New python executable in foobar/bin/python
Changed mode of foobar/bin/python to 0775
Copying to foobar/bin/python2
Copying to foobar/bin/python2.7
Testing executable with foobar/bin/python -c "import sys;out=sys.stdout;getattr(out, "buffer", out).write(sys.prefix.encode("utf-8"))"
Got sys.prefix result: u'/home/vagrant/foobar'
Creating foobar/lib64/python2.7/distutils
Writing foobar/lib64/python2.7/distutils/__init__.py
Writing foobar/lib64/python2.7/distutils/distutils.cfg
Installing setuptools, pip...
  Traceback (most recent call last):
    File "<string>", line 1, in <module>
    File "/usr/lib/python2.7/site-packages/virtualenv_support/pip-1.5.4-py2.py3-none-any.whl/pip/__init__.py", line 9, in <module>
    File "/usr/lib/python2.7/site-packages/virtualenv_support/pip-1.5.4-py2.py3-none-any.whl/pip/log.py", line 6, in <module>
    File "/usr/lib64/python2.7/logging/__init__.py", line 26, in <module>
      import sys, os, time, cStringIO, traceback, warnings, weakref
  ImportError: No module named time
  Complete output from command /home/vagrant/foobar/bin/python -c "import sys, pip; sys...d\"] + sys.argv[1:]))" setuptools pip:
  Traceback (most recent call last):
  File "<string>", line 1, in <module>
  File "/usr/lib/python2.7/site-packages/virtualenv_support/pip-1.5.4-py2.py3-none-any.whl/pip/__init__.py", line 9, in <module>
  File "/usr/lib/python2.7/site-packages/virtualenv_support/pip-1.5.4-py2.py3-none-any.whl/pip/log.py", line 6, in <module>
  File "/usr/lib64/python2.7/logging/__init__.py", line 26, in <module>
    import sys, os, time, cStringIO, traceback, warnings, weakref
ImportError: No module named time
----------------------------------------
...Installing setuptools, pip...done.
Traceback (most recent call last):
  File "/usr/bin/virtualenv", line 11, in <module>
    sys.exit(main())
  File "/usr/lib/python2.7/site-packages/virtualenv.py", line 824, in main
    symlink=options.symlink)
  File "/usr/lib/python2.7/site-packages/virtualenv.py", line 992, in create_environment
    install_wheel(to_install, py_executable, search_dirs)
  File "/usr/lib/python2.7/site-packages/virtualenv.py", line 960, in install_wheel
    'PIP_NO_INDEX': '1'
  File "/usr/lib/python2.7/site-packages/virtualenv.py", line 902, in call_subprocess
    % (cmd_desc, proc.returncode))
OSError: Command /home/vagrant/foobar/bin/python -c "import sys, pip; sys...d\"] + sys.argv[1:]))" setuptools pip failed with error code 1

Voici la sortie détaillée complète en cas de succès :

[vagrant<strong i="6">@localhost</strong> ~]$ virtualenv --always-copy --clear --verbose --no-setuptools foobar
Do not need to delete foobar/lib/python2.7; already gone
Not deleting foobar/bin
Creating foobar/lib/python2.7
Cannot find file lib (bad symlink)
Symlinking Python bootstrap modules
  Copying to foobar/lib/python2.7/config
  Copying to foobar/lib/python2.7/lib-dynload
  Creating parent directories for foobar/lib64/python2.7
  Copying to foobar/lib64/python2.7/os.py
  Ignoring built-in bootstrap module: posix
  Copying to foobar/lib64/python2.7/posixpath.py
  Cannot import bootstrap module: nt
  Copying to foobar/lib64/python2.7/ntpath.py
  Copying to foobar/lib64/python2.7/genericpath.py
  Copying to foobar/lib64/python2.7/fnmatch.py
  Copying to foobar/lib64/python2.7/locale.py
  Copying to foobar/lib64/python2.7/encodings
  Copying to foobar/lib64/python2.7/codecs.py
  Copying to foobar/lib64/python2.7/stat.py
  Copying to foobar/lib64/python2.7/UserDict.py
  Creating parent directories for foobar/lib64/python2.7/lib-dynload
  Copying to foobar/lib64/python2.7/lib-dynload/readline.so
  Copying to foobar/lib64/python2.7/copy_reg.py
  Copying to foobar/lib64/python2.7/types.py
  Copying to foobar/lib64/python2.7/re.py
  Copying to foobar/lib64/python2.7/sre.py
  Copying to foobar/lib64/python2.7/sre_parse.py
  Copying to foobar/lib64/python2.7/sre_constants.py
  Copying to foobar/lib64/python2.7/sre_compile.py
  Copying to foobar/lib64/python2.7/lib-dynload/zlibmodule.so
  Copying to foobar/lib64/python2.7/warnings.py
  Copying to foobar/lib64/python2.7/linecache.py
  Copying to foobar/lib64/python2.7/_abcoll.py
  Copying to foobar/lib64/python2.7/abc.py
  Copying to foobar/lib64/python2.7/_weakrefset.py
Creating foobar/lib/python2.7/site-packages
Writing foobar/lib64/python2.7/site.py
Writing foobar/lib64/python2.7/orig-prefix.txt
Writing foobar/lib64/python2.7/no-global-site-packages.txt
Creating parent directories for foobar/include
Copying to foobar/include/python2.7
Creating foobar/bin
New python executable in foobar/bin/python
Changed mode of foobar/bin/python to 0775
Copying to foobar/bin/python2
Copying to foobar/bin/python2.7
Testing executable with foobar/bin/python -c "import sys;out=sys.stdout;getattr(out, "buffer", out).write(sys.prefix.encode("utf-8"))"
Got sys.prefix result: u'/home/vagrant/foobar'
Creating foobar/lib64/python2.7/distutils
Writing foobar/lib64/python2.7/distutils/__init__.py
Writing foobar/lib64/python2.7/distutils/distutils.cfg
Writing foobar/bin/activate
Writing foobar/bin/activate.fish
Writing foobar/bin/activate_this.py
Writing foobar/bin/activate.csh

Dans les cas d'échec et de réussite, la première ligne d'erreur est :

Cannot find file lib (bad symlink)

Ce journal n'est pas utile car je n'ai pas le chemin complet du fichier qu'il ne peut pas trouver. J'ai donc piraté virtualenv.py pour imprimer os.path.abspath pour ce fichier et j'ai obtenu :

Cannot find file /home/vagrant/lib (bad symlink)

Il recherche un dossier lib dans le répertoire de travail actuel.

le même ici sur Centos7 avec stock python 2.7

$ virtualenv --always-copy /opt/
New python executable in /opt/bin/python
Installing setuptools, pip...
  Complete output from command /opt/bin/python -c "import sys, pip; sys...d\"] + sys.argv[1:]))" setuptools pip:
  Traceback (most recent call last):
  File "<string>", line 1, in <module>
  File "/usr/lib/python2.7/site-packages/virtualenv_support/pip-6.0.6-py2.py3-none-any.whl/pip/__init__.py", line 4, in <module>
  File "/usr/lib64/python2.7/logging/__init__.py", line 26, in <module>
    import sys, os, time, cStringIO, traceback, warnings, weakref
ImportError: No module named time
----------------------------------------
...Installing setuptools, pip...done.
Traceback (most recent call last):
  File "/usr/bin/virtualenv", line 11, in <module>
    sys.exit(main())
  File "/usr/lib/python2.7/site-packages/virtualenv.py", line 825, in main
    symlink=options.symlink)
  File "/usr/lib/python2.7/site-packages/virtualenv.py", line 993, in create_environment
    install_wheel(to_install, py_executable, search_dirs)
  File "/usr/lib/python2.7/site-packages/virtualenv.py", line 961, in install_wheel
    'PIP_NO_INDEX': '1'
  File "/usr/lib/python2.7/site-packages/virtualenv.py", line 903, in call_subprocess
    % (cmd_desc, proc.returncode))
OSError: Command /opt/bin/python -c "import sys, pip; sys...d\"] + sys.argv[1:]))" setuptools pip failed with error code 1

Pareil ici. En utilisant --always-copy sur CentOS 6.5, le système Python 2.6 se retrouve avec le même ImportError: No module named time comme mentionné.

la solution est d'oublier l'option --always-copy sur les distributions basées sur EL

il semble y avoir une faute de frappe dans la fonction fix_lib64 en cours d'exécution. Je corrige cela et cela fonctionne comme prévu. aller à la ligne :

   1579         if symlink:                              
   1580             os.symlink('lib', lib64_link)      
   1581         else:                                    
   1582             copyfile('lib', lib64_link)        

remplacer 'lib' par lib_dir

  1579         if symlink:                              
   1580             os.symlink(lib_dir, lib64_link)      
   1581         else:                                    
   1582             copyfile(lib_dir, lib64_link)        

En retard, mais j'espère que cela t'aidera

J'ai également le même problème ici en utilisant CentOS 7.1 avec les indicateurs --no-setup-tools et --always-copy . J'aimerais que cela soit corrigé car j'emballe le virtualenv et je l'expédie aux clients (qui sont également sur CentOS7+, donc ce n'est pas un risque majeur).

Idem ici sur Gentoo x86_64 avec --always-copy .

@jdelgad et @selurvedu avez-vous essayé ce que j'ai recommandé ci-dessus ?

@ikiini Oui, votre patch résout le problème.

@ikiini Ça a marché ! Merci beaucoup. Maintenant, placez-le dans RHEL 7 ou dans la branche principale.

+1

super. Désolé pour la réponse tardive..mais vous êtes les bienvenus

Le seul problème semble être que le correctif de https://github.com/pypa/virtualenv/issues/338, qui est en fait passé de lib_dir à 'lib'

Le problème persiste avec CentOS 7 et python 2.7

[root@st2w-master-el7-5696a8a082 ~]# virtualenv no_copy
New python executable in no_copy/bin/python
Installing setuptools, pip, wheel...done.
[root@st2w-master-el7-5696a8a082 ~]# virtualenv --always-copy yes_copy
Cannot find file lib (bad symlink)
New python executable in yes_copy/bin/python
Installing setuptools, pip, wheel...
  Complete output from command /root/yes_copy/bin/python -c "import sys, pip; sys...d\"] + sys.argv[1:]))" setuptools pip wheel:
  Traceback (most recent call last):
  File "<string>", line 1, in <module>
  File "/usr/lib/python2.7/site-packages/virtualenv_support/pip-7.1.2-py2.py3-none-any.whl/pip/__init__.py", line 4, in <module>
  File "/usr/lib64/python2.7/logging/__init__.py", line 26, in <module>
    import sys, os, time, cStringIO, traceback, warnings, weakref
ImportError: No module named time
----------------------------------------
...Installing setuptools, pip, wheel...done.
Traceback (most recent call last):
  File "/bin/virtualenv", line 11, in <module>
    sys.exit(main())
  File "/usr/lib/python2.7/site-packages/virtualenv.py", line 832, in main
    symlink=options.symlink)
  File "/usr/lib/python2.7/site-packages/virtualenv.py", line 1004, in create_environment
    install_wheel(to_install, py_executable, search_dirs)
  File "/usr/lib/python2.7/site-packages/virtualenv.py", line 969, in install_wheel
    'PIP_NO_INDEX': '1'
  File "/usr/lib/python2.7/site-packages/virtualenv.py", line 910, in call_subprocess
    % (cmd_desc, proc.returncode))
OSError: Command /root/yes_copy/bin/python -c "import sys, pip; sys...d\"] + sys.argv[1:]))" setuptools pip wheel failed with error code 1
[root@st2w-master-el7-5696a8a082 ~]# virtualenv --version
13.1.2
[root@st2w-master-el7-5696a8a082 ~]# ls -rlth yes_copy/
total 0
drwxr-xr-x. 3 root root 22 Jan 13 22:04 lib
drwxr-xr-x. 3 root root 22 Jan 13 22:04 lib64
drwxr-xr-x. 3 root root 22 Jan 13 22:04 include
drwxr-xr-x. 2 root root 49 Jan 13 22:04 bin
[root@st2w-master-el7-5696a8a082 ~]#

@ bwilliams42 - Votre modification a en effet résolu le problème de la logique de liaison symbolique. Cependant, les choses sont fondamentalement cassées lorsque vous n'utilisez pas --always-copy. Notez que copyfile a un kwarg "symlink" qui par défaut est True. La logique suivante est effectivement, si symlink, appelez os.symlink, sinon appelez copyfile sans le "symlink" kwarg qui entraîne la valeur par défaut du fichier de copie symlink=True et un lien symbolique est créé par copyfile. Pas utile du tout. Un lien symbolique est le résultat quoi qu'il arrive.

Le patch ne devrait-il pas ressembler à ce qui suit ?

   1579         if symlink:                              
   1580             os.symlink(lib_dir, lib64_link)      
   1581         else:                                    
   1582             copyfile(lib_dir, lib64_link, symlink=symlink)

J'ai eu un problème avec lequel j'ai fait cela et j'ai eu un lien symbolique vers /usr/lib64. Lorsque RH a mis à jour certaines des bibliothèques openssl, cela était cassé (j'utilisais ansible) avec une erreur indiquant quelque chose comme openssl_meth function . Je l'ai corrigé en faisant une copie complète de /usr/lib64. Pas une solution complète @bwilliams42 mais m'a

Le problème persiste toujours sur Centos 7.2. Ce billet a été signalé il y a 2,5 ans. Il semble que ce soit un problème très grave. Comment puis-je aider à le réparer ?

Quelqu'un doit fournir un correctif fonctionnel. Il y a un correctif qui a été proposé ici, mais il a apparemment quelques problèmes. Je suggère de commencer par là.

BTW, j'essaie de créer et d'emballer mon application python dans un environnement virtuel sur une machine virtuelle spéciale sous Vagrant avec l'aide de Fabric, il est donc assez facile de reproduire ce bogue avec Vagrant + centos box + script Fabric simple.

Je n'ai pas de connaissances internes sur la façon dont virtualenv est censé fonctionner, j'ai donc besoin de conseils.

Je ne peux pas aider, désolé, car je suis sous Windows, et toute la question du lien symbolique contre la copie (ou les répertoires lib64, qui semblent impliqués dans cela) n'est pas pertinente ici.

Intéressant que (je suis sur Amazon Linux) quand je fais virtualenv --always-copy app j'obtiens cette erreur ( Cannot find file lib (bad symlink) ) mais quand je fais mkdir app; cd app; virtualenv --always-copy . je ne le fais pas. Et il semble que je comprenne pourquoi - lorsque le app est créé par le virtualenv, il a lib64 comme répertoire, mais lorsque je crée le virtualenv dans le répertoire actuel, il devient un lien vers lib .

virtualenv.py > def path_locations commence par ce commentaire :

XXX : Nous utiliserions distutils.sysconfig.get_python_inc/lib mais son
le préfixe arg est cassé : http://bugs.python.org/issue3386

Ce problème a été résolu il y a une dizaine d'années. Peut-être reconsidérer son utilisation ?
Donner juste un autre angle ; écrire un correctif fiable pour toutes les plates-formes n'est en aucun cas une tâche facile.

@kika Merci beaucoup.

Ce problème a été automatiquement marqué comme obsolète car il n'a pas eu d'activité récente. Il sera fermé si aucune autre activité ne se produit. Ajoutez simplement un commentaire si vous voulez le garder ouvert. Merci pour vos contributions.

Cela devient obsolète avec le #1366 qui bat son plein. Nous rouvrirons si quelqu'un peut encore répliquer avec ça.