virtualenv: Breakage in --always-copy - fails with: ImportError: No module named time

On CentOS 6.5 (python2.7 from SCL):

[dev@centbox core]$ virtualenv-2.7 --always-copy .break
sys.path (patched logging) = ['/opt/rh/python27/root/usr/bin', '/opt/rh/python27/root/usr/lib/python2.7/site-packages/setuptools-2.2-py2.7.egg', '/opt/rh/python27/root/usr/lib/python2.7/site-packages/wheel-0.22.0-py2.7.egg', '/opt/rh/python27/root/usr/lib/python2.7/site-packages/virtualenv-1.11.2-py2.7.egg', '/opt/rh/python27/root/usr/lib/python2.7/site-packages/pip-1.5.2-py2.7.egg', '/opt/rh/python27/root/usr/lib64/python27.zip', '/opt/rh/python27/root/usr/lib64/python2.7', '/opt/rh/python27/root/usr/lib64/python2.7/plat-linux2', '/opt/rh/python27/root/usr/lib64/python2.7/lib-tk', '/opt/rh/python27/root/usr/lib64/python2.7/lib-old', '/opt/rh/python27/root/usr/lib64/python2.7/lib-dynload', '/opt/rh/python27/root/usr/lib64/python2.7/site-packages', '/opt/rh/python27/root/usr/lib/python2.7/site-packages']
Cannot find file lib (bad symlink)
New python executable in .break/bin/python2.7
Also creating executable in .break/bin/python
Installing setuptools, pip...
  Complete output from command /home/dev/core/.break/bin/python2.7 -c "import sys, pip; sys...d\"] + sys.argv[1:]))" setuptools pip:
  Traceback (most recent call last):
  File "<string>", line 1, in <module>
  File "/opt/rh/python27/root/usr/lib/python2.7/site-packages/virtualenv-1.11.2-py2.7.egg/virtualenv_support/pip-1.5.2-py2.py3-none-any.whl/pip/__init__.py", line 9, in <module>
  File "/opt/rh/python27/root/usr/lib/python2.7/site-packages/virtualenv-1.11.2-py2.7.egg/virtualenv_support/pip-1.5.2-py2.py3-none-any.whl/pip/log.py", line 6, in <module>
  File "/opt/rh/python27/root/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 "/opt/rh/python27/root/usr/bin/virtualenv-2.7", line 9, in <module>
    load_entry_point('virtualenv==1.11.2', 'console_scripts', 'virtualenv-2.7')()
  File "/opt/rh/python27/root/usr/lib/python2.7/site-packages/virtualenv-1.11.2-py2.7.egg/virtualenv.py", line 824, in main
    symlink=options.symlink)
  File "/opt/rh/python27/root/usr/lib/python2.7/site-packages/virtualenv-1.11.2-py2.7.egg/virtualenv.py", line 992, in create_environment
    install_wheel(to_install, py_executable, search_dirs)
  File "/opt/rh/python27/root/usr/lib/python2.7/site-packages/virtualenv-1.11.2-py2.7.egg/virtualenv.py", line 960, in install_wheel
    'PIP_NO_INDEX': '1'
  File "/opt/rh/python27/root/usr/lib/python2.7/site-packages/virtualenv-1.11.2-py2.7.egg/virtualenv.py", line 902, in call_subprocess
    % (cmd_desc, proc.returncode))
OSError: Command /home/dev/core/.break/bin/python2.7 -c "import sys, pip; sys...d\"] + sys.argv[1:]))" setuptools pip failed with error code 1

Works fine without it:

[dev@centbox core]$ virtualenv-2.7 .works
sys.path (patched logging) = ['/opt/rh/python27/root/usr/bin', '/opt/rh/python27/root/usr/lib/python2.7/site-packages/setuptools-2.2-py2.7.egg', '/opt/rh/python27/root/usr/lib/python2.7/site-packages/wheel-0.22.0-py2.7.egg', '/opt/rh/python27/root/usr/lib/python2.7/site-packages/virtualenv-1.11.2-py2.7.egg', '/opt/rh/python27/root/usr/lib/python2.7/site-packages/pip-1.5.2-py2.7.egg', '/opt/rh/python27/root/usr/lib64/python27.zip', '/opt/rh/python27/root/usr/lib64/python2.7', '/opt/rh/python27/root/usr/lib64/python2.7/plat-linux2', '/opt/rh/python27/root/usr/lib64/python2.7/lib-tk', '/opt/rh/python27/root/usr/lib64/python2.7/lib-old', '/opt/rh/python27/root/usr/lib64/python2.7/lib-dynload', '/opt/rh/python27/root/usr/lib64/python2.7/site-packages', '/opt/rh/python27/root/usr/lib/python2.7/site-packages']
New python executable in .works/bin/python2.7
Also creating executable in .works/bin/python
Installing setuptools, pip...done.
[dev@centbox core]$

About this issue

Original URL
State: closed
Created 10 years ago
Comments: 26 (3 by maintainers)

Commits related to this issue

Tweaks to provisioning and make file to work in VM as Windows host. Ran into a virtualization error that took a while to debug: https://github.com/gratipay/gratipay.com/issues/2327 https://github.com... — committed to pjfontillas/dutchman by pjfontillas 8 years ago
Supposed typo: https://github.com/pypa/virtualenv/issues/565#issuecomment-115036122, On CentOS 7 building certain projects fails without this "fix". Also relevant, https://github.com/spotify/dh-virtua... — committed to Neurocinetics/virtualenv by deleted user 7 years ago

Most upvoted comments

Interesting that (I’m on Amazon Linux) when I do virtualenv --always-copy app I get this error (Cannot find file lib (bad symlink)) but when I do mkdir app; cd app; virtualenv --always-copy . I do not. And it seems I understand why - when the app is created by the virtualenv it has lib64 as a directory, but when I create the virtualenv in the current directory it becomes a link to lib.

+11

kika on May 30, 2017

there seems to be a typo in the fix_lib64 function that is currently running. I correct this and it works as expected. go to line:

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

replace 'lib' with lib_dir

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

Late, but hope this helps

bwilliams42 on Jun 24, 2015

Problem still persists on Centos 7.2. This ticket has been reported 2.5 years ago. It seems it’s very serious problem. How can I help to fix it?

bialix on Oct 18, 2016

I’m getting the same problem here as well using CentOS 7.1 with flags --no-setup-tools and --always-copy. I’d love for this to be fixed since I’m packaging up the virtualenv and shipping them to customers (that are also on CentOS7+ so it’s not a major risk).

jdelgad on Jul 10, 2015

This is becoming obsolete with #1366 now in full swing. We’ll reopen if someone can still replicate with that.

gaborbernat on Dec 23, 2019