9

I am running a django project with a virtualenv that was working completely fine up until this afternoon. I went to run source my-env/bin/activate and it seemed to activate (it gave me the usual command prompt), but when I tried python manage.py runserver it said it could not locate django. I ran a python script and tried to import django and sure enough it said there was no module named django. So I removed this virtualenv and created a new one and did a pip install -r requirements.txt. It was then I noticed that pip was hanging forever and upon type ^C it would give a long traceback which I provided below. Once this happened I tried once again to delete the virtualenv and start over only now when I typed virtualenv new-env it would hang on "Installing setuptools, pip, wheel..." and also gave a long traceback upon entering ^C. I have looked all over the online forums and tried everything to fix this and nothing seems to be working. If anyone has any ideas on how to fix this I would really appreciate it.

Installing setuptools, pip, wheel...^CTraceback (most recent call last):
  File "/usr/local/bin/virtualenv", line 11, in <module>
done.
    sys.exit(main())
  File "/usr/local/lib/python2.7/site-packages/virtualenv.py", line 669, in main
Traceback (most recent call last):
  File "/usr/local/lib/python2.7/site-packages/virtualenv.py", line 2327, in <module>
    raise SystemExit(popen.wait())
  File "/usr/local/Cellar/python/2.7.11/Frameworks/Python.framework/Versions/2.7/lib/python2.7/subprocess.py", line 1384, in wait
    main()
  File "/usr/local/lib/python2.7/site-packages/virtualenv.py", line 711, in main
    symlink=options.symlink)
  File "/usr/local/lib/python2.7/site-packages/virtualenv.py", line 944, in create_environment
    download=download,
  File "/usr/local/lib/python2.7/site-packages/virtualenv.py", line 900, in install_wheel
    call_subprocess(cmd, show_stdout=False, extra_env=env, stdin=SCRIPT)
  File "/usr/local/lib/python2.7/site-packages/virtualenv.py", line 767, in call_subprocess
    line = stdout.readline()
KeyboardInterrupt
    pid, sts = _eintr_retry_call(os.waitpid, self.pid, 0)
  File "/usr/local/Cellar/python/2.7.11/Frameworks/Python.framework/Versions/2.7/lib/python2.7/subprocess.py", line 476, in _eintr_retry_call
    return func(*args)
KeyboardInterrupt
Anthony
  • 670
  • 6
  • 20
  • I was able to do a workaround by creating a new virtualenv by using the command python3 -m venv new-env, but pip was still hanging afterwards. Pip however will work if I use --no-cache-dir. This is still very inconvenient as I would like to be able to use mkvirtualenv, but this also doesn't work. – Cameron Pattisall Oct 17 '16 at 19:22
  • Possible duplicate of [setting up environment in virtaulenv using python3 stuck on setuptools, pip, wheel](https://stackoverflow.com/questions/45674311/setting-up-environment-in-virtaulenv-using-python3-stuck-on-setuptools-pip-whe) – Vineet Jain Nov 03 '17 at 07:30

3 Answers3

7

Probably not very helpful, but I experienced the same symptoms and found using the verbose option to be helpful:

mkvirtualenv new-env -v

The output pointed at a proxy issue I had, preventing usage of setuptools, which I resolved by fixing my proxy settings:

Installing setuptools, pip, wheel...
Collecting setuptools
Retrying (Retry(total=4, connect=None, read=None, redirect=None)) 
after connection broken by 'ProxyError('Cannot connect to proxy.', 
timeout('timed out',))': /devpi/setuptools/
user10000000
  • 311
  • 3
  • 9
5

I was having a lot of trouble with this and nothing I tried from various StackOverflow discussions was helping. I had made absolutely certain it was not a networking issue, and in fact I was hoping that upgrading from Ubuntu 16 to 18 would magically fix it... but it didn't. So I figured I had to actually fix it.

I was beginning to suspect it had something to do with my user directory because it worked when I tried it as the root user. Furthermore, I had copied my entire home directory to a temporary disk and then back to the main hard drive after the uprade (because I wanted a fresh install of Ubuntu 18's "minimal" option). So I was beginning to suspect that something in my home folder was culpable.

Running virtualenv with the -vv option only showed that it was stopping on: Collecting setuptools.

Considering that many were recommending checking the internet connection, I figured it might be something related to cache. So I tried emptying the ~/.cache directory with:

rm -rf ~/.cache/*

Immediately the virtualenv command that was hanging in another terminal window continued and finished within some seconds.

I don't know if emptying the cache in this manner with a bunch of applications running is considered brave, but anyway, it did the trick.

Update

@t354 suggests only removing ~/.cache/pip with:

rm -rf ~/.cache/pip

Haven't tried it myself, but if it works as well, then it's probably safer than deleting everything inside ~/.cache

Teekin
  • 12,581
  • 15
  • 55
  • 67
  • 1
    I tried `rm -rf ~/.cache/pip` before resorting to the full nuclear option, and that seemed to work fine for me. – t354 Apr 10 '19 at 13:24
  • @t354: That makes far more sense and is probably safer. I'll add that to the answer. Thanks! – Teekin May 02 '19 at 22:31
  • I had a similar issue, there was a lock file in the cache that seemed to cause it to hang. You could see this with adding "--log /tmp/pip.log" to the pip command then looking at the log. I simply trashed the cache/pip and it resolved it also but I guess you could simply remove the lock file – Lol Jan 21 '20 at 18:33
  • `rm -rf ~/.cache/*` fixed all my issues regarding pip/virtualenv hanging. Thanks! – Salyangoz Jun 16 '20 at 20:11
0

Dude I solved this issue after a long period of pain.
Reinstalling the following packages pip \ setuptools \ wheels with a couple of option.

python -m pip install <package_name> --upgrade --force-reinstall --no-binary <package_name>    

Probably the issue was due to a not backward compatibility of a version of one of the package above.

bull90
  • 689
  • 5
  • 12