Setting up a virtualenv: No module named 'pip&

Question

I have a fresh install of Python 3.3.4 on a Windows Server 2008 R2 machine. I've successfully installed the latest versions of Setuptools, Pip and Virtualenv globally:

python ez_setup.py
easy_install pip
pip install virtualenv

Now when I try to set up a virtualenv using virtualenv ENV I get the following stack trace:

New python executable in ENV\Scripts\python.exe
Installing setuptools, pip...
  Complete output from command [path redacted]\ENV\Scripts\python.exe -c "import sys, pip; sys...d\"] + sys.argv[1:]))" setuptools pip:
  Traceback (most recent call last):
  File "<string>", line 1, in <module>
ImportError: No module named 'pip'
----------------------------------------
...Installing setuptools, pip...done.
Traceback (most recent call last):
  File "C:\Python33\lib\runpy.py", line 160, in _run_module_as_main
    "__main__", fname, loader, pkg_name)
  File "C:\Python33\lib\runpy.py", line 73, in _run_code
    exec(code, run_globals)
  File "C:\Python33\Scripts\virtualenv.exe\__main__.py", line 9, in <module>
  File "C:\Python33\lib\site-packages\virtualenv.py", line 824, in main
    symlink=options.symlink)
  File "C:\Python33\lib\site-packages\virtualenv.py", line 992, in create_environment
    install_wheel(to_install, py_executable, search_dirs)
  File "C:\Python33\lib\site-packages\virtualenv.py", line 960, in install_wheel
    'PIP_NO_INDEX': '1'
  File "C:\Python33\lib\site-packages\virtualenv.py", line 902, in call_subprocess
    % (cmd_desc, proc.returncode))
OSError: Command [path redacted]\ENV\Scripts\python.exe -c "import sys, pip; sys...d\"] + sys.argv[1:]))" setuptools pip failed with error code 1

I've never seen this error before, and the stack trace doesn't make any sense to me. I can successfully import pip from a Python shell. Can anyone help me fix this?

Update The env installs successfully when I supply the --system-site-packages flag.

Answer 1

Annoyingly, it looks like this might be a Python bug. https://github.com/pypa/virtualenv/issues/564 references http://bugs.python.org/issue20621, which is still open but looks like it's going to be fixed in 3.3.5.

Dropping my Python installation back down to 3.3.3 fixed the issue.

Answer 2

Useful workaround from the Python bug ticket for anybody else with this issue:

• Run virtualenv venv --no-setuptools
• Activate that virtualenv (venv\Scripts\activate)
• Download and run get-pip.py to manually install pip & setuptools into this virtualenv
• Continue as normal

Alternatively, downgrade to 3.3.3. This should be fixed properly in 3.3.5