Virtualenv: La rotura en --always-copy - falla con: ImportError: Ningún módulo con nombre time

También estoy abordando este problema, pero como solución alternativa, puede agregar no-setuptools para no instalar pip en su virtualenv. Este problema está relacionado con la instalación de pip / setuptools en el nuevo virtualenv.

Mi información de versión:

• Fedora 19 x86_64,
• Instalación del sistema de Python 2.7.5
• virtualenv 1.11.4
• pip 1.5.4

Aquí está la salida detallada completa en caso de falla:

[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

Aquí está la salida detallada completa sobre el éxito:

[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

Tanto en los casos fallidos como exitosos, la primera línea de error es:

Cannot find file lib (bad symlink)

Este registro no es útil porque no tengo la ruta completa al archivo que no puede encontrar. Por lo tanto, pirateé virtualenv.py para imprimir os.path.abspath para este archivo y obtuve:

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

Está buscando una carpeta lib en el directorio de trabajo actual.

lo mismo aquí en Centos7 con 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

Aquí igual. Usando --always-copy en CentOS 6.5, el sistema Python 2.6 termina con el mismo ImportError: No module named time que se mencionó.

la solución es olvidarse de la opción --always-copy en distribuciones basadas en EL

parece haber un error tipográfico en la función fix_lib64 que se está ejecutando actualmente. Corregí esto y funciona como se esperaba. ir a la línea:

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

reemplace 'lib' con lib_dir

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

Tarde, pero espero que esto ayude

También tengo el mismo problema aquí al usar CentOS 7.1 con las banderas --no-setup-tools y --always-copy . Me encantaría que esto se solucione, ya que estoy empaquetando el virtualenv y enviándolo a los clientes (que también están en CentOS7 +, por lo que no es un riesgo importante).

Lo mismo aquí en Gentoo x86_64 con --always-copy .

@jdelgad y @selurvedu, ¿

@ikiini Sí, tu parche resuelve el problema.

@ikiini ¡ Funcionó! Muchas gracias. Ahora, ingrese esto en RHEL 7 o en la rama principal.

+1

estupendo. Disculpe la demora en la respuesta ... pero de nada, @selurvedu y @jdelgad.

El único problema parece ser que el parche de @ikiini parece retroceder en https://github.com/pypa/virtualenv/issues/338, que es cuando en realidad se cambió de lib_dir a 'lib'

El problema aún persiste con CentOS 7 y 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 : su cambio solucionó el problema de la lógica de enlace simbólico. Sin embargo, las cosas se rompen fundamentalmente cuando no se usa --always-copy. Tenga en cuenta que el archivo de copia tiene un kwarg de "enlace simbólico" cuyo valor predeterminado es Verdadero. La siguiente lógica es efectivamente, si el enlace simbólico, llama a os.symlink, de lo contrario llama al archivo de copia sin el kwarg "enlace simbólico", lo que da como resultado que el archivo de copia tenga por defecto el enlace simbólico = Verdadero y se crea un enlace simbólico mediante el archivo de copia. No es útil en absoluto. Un enlace simbólico es el resultado sin importar qué.

¿No debería ser el parche algo como lo siguiente?

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

Tuve un problema por el cual hice esto y tenía un enlace simbólico a / usr / lib64. Cuando RH actualizó algunas de las bibliotecas de openssl, esto estaba roto (estaba usando ansible) con un error que indicaba algo como openssl_meth function . Lo arreglé haciendo una copia profunda de / usr / lib64. No es una solución completa @ bwilliams42, pero me indicó la dirección correcta.

El problema aún persiste en Centos 7.2. Este ticket se informó hace 2,5 años. Parece que es un problema muy serio. ¿Cómo puedo ayudar a solucionarlo?

Alguien debe proporcionar una solución que funcione. Aquí se ha propuesto una solución, pero aparentemente tiene un par de problemas. Sugeriría empezar por ahí.

Por cierto, estoy tratando de compilar y empaquetar mi aplicación de Python en un entorno virtual en una VM especial en Vagrant con la ayuda de fabric, por lo que es bastante fácil reproducir este error con Vagrant + centos box + script de tela simple.

No tengo un conocimiento interno sobre cómo se supone que funciona virtualenv, por lo que necesito orientación.

No puedo evitarlo, lo siento, ya que estoy en Windows, y toda la cuestión del enlace simbólico frente a la copia (o los directorios lib64, que parecen involucrados en esto) no es relevante allí.

Es interesante que (estoy en Amazon Linux) cuando hago virtualenv --always-copy app obtengo este error ( Cannot find file lib (bad symlink) ) pero cuando hago mkdir app; cd app; virtualenv --always-copy . no. Y parece que entiendo por qué: cuando el virtualenv crea el app , tiene lib64 como directorio, pero cuando creo el virtualenv en el directorio actual, se convierte en un enlace a lib .

virtualenv.py > def path_locations comienza con este comentario:

XXX: Usaríamos distutils.sysconfig.get_python_inc / lib pero es
el prefijo arg está roto: http://bugs.python.org/issue3386

Este problema se resolvió hace unos diez años. ¿Quizás reconsiderar su uso?
Solo dando otro ángulo; escribir una solución confiable para todas las plataformas no es una tarea fácil.

@kika Muchas gracias.

Este problema se ha marcado automáticamente como obsoleto porque no ha tenido actividad reciente. Se cerrará si no se produce más actividad. Simplemente agregue un comentario si desea mantenerlo abierto. Gracias por sus aportaciones.

Esto se está volviendo obsoleto con el # 1366 ahora en pleno apogeo. Volveremos a abrir si alguien todavía puede replicar con eso.