Failure to install wheel when using --always-copy

[terminalmage]

This is on Python 2.7.12 and virtualenv 15.0.3, both installed on CentOS 5 and packaged by the IUS Community project.

When I try to create a virtualenv with --always-copy, it fails with the following error:

# virtualenv-2.7 --no-site-packages --always-copy foo
Cannot find file lib (bad symlink)
New python executable in /root/foo/bin/python2.7
Also creating executable in /root/foo/bin/python
Installing setuptools, pip, wheel...
  Complete output from command /root/foo/bin/python2.7 - setuptools pip wheel:
  Traceback (most recent call last):
  File "<stdin>", line 4, in <module>
  File "/usr/lib64/python2.7/tempfile.py", line 32, in <module>
    import io as _io
  File "/usr/lib64/python2.7/io.py", line 51, in <module>
    import _io
ImportError: No module named _io
----------------------------------------
...Installing setuptools, pip, wheel...done.
Traceback (most recent call last):
  File "/usr/bin/virtualenv-2.7", line 9, in <module>
    load_entry_point('virtualenv==15.0.3', 'console_scripts', 'virtualenv')()
  File "/usr/lib/python2.7/site-packages/virtualenv.py", line 710, in main
    symlink=options.symlink)
  File "/usr/lib/python2.7/site-packages/virtualenv.py", line 946, in create_environment
    download=download,
  File "/usr/lib/python2.7/site-packages/virtualenv.py", line 902, in install_wheel
    call_subprocess(cmd, show_stdout=False, extra_env=env, stdin=SCRIPT)
  File "/usr/lib/python2.7/site-packages/virtualenv.py", line 794, in call_subprocess
    % (cmd_desc, proc.returncode))
OSError: Command /root/foo/bin/python2.7 - setuptools pip wheel failed with error code 1

Tracking this down in virtualenv.py, this is caused by install_wheel() running an embedded script using a munged pythonpath (assembled here and containing only the paths of the wheels found by find_wheels()). The problem with this is that the embedded python script which install_wheel() wants to run imports tempfile, which eventually needs to import _io.so from /usr/lib64/python2.7/lib-dynload.

I was able to get it fixed with this commit, but rather than just opening a PR I thought I'd post my findings here and see if there isn't a more elegant solution from someone more experienced with this codebase.

[terminalmage]

That's not the only weirdness with lib-dynload. The virtualenv has for some reason split the .so files into lib/python2.7/lib-dynload and lib64/python2.7/lib-dynload directories, but only lib64/python2.7/lib-dynload ends up in sys.path.

[spacefito]

I am seeing the same error with virtualenv 15.1.0 on suse leap 42.2 and sles 12 sp2

[spacefito]

https://github.com/pypa/virtualenv/pull/1010/commits
solves this problem on suse 42.2

[srinathgs]

@spacefito 's solution works for me too on centos

[stale]

This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. Just add a comment if you want to keep it open. Thank you for your contributions.

[terminalmage]

The linked pull request seems like a better solution than mine, and since it appears to have fixed this issue for others, I think this can be considered fixed. Therefore, I will close this. Thanks!