1

I'm trying out virtualenv for my django projects and I'm running into some hiccups. Using a webfaction account.

Right now I've got a virtualenv set up and I'm trying to install Django 1.8.2, but when I enter "pip install Django" OR "pip install Django==1.8.2" it always just installs Django-1.7.8 and uses that as the active version.

Here's some code from my command line:

(django_test)[pattmayne@web476 django_test]$ pip install Django==1.8.2
Collecting Django==1.8.2
  Using cached Django-1.8.2-py2.py3-none-any.whl
Installing collected packages: Django
  Found existing installation: Django 1.7.8
    Not uninstalling Django at /home/pattmayne/lib/python3.4/Django-1.7.8-py3.4.egg, outside environment /home/pattmayne/webapps/django_test
Successfully installed Django-1.7.8

Then I test the version of django-admin:

(django_test)[pattmayne@web476 django_test]$ django-admin.py --version
1.7.8

I get the same result when I try django-1.8.0 or 1.8.1

Does anybody know what I'm doing wrong?

When I set up the virtualenv I wrote:

virtualenv . --no-site-packages

So it shouldn't even be acknowledging old installations, should it? This is just a test case so I have no problem deleting it all and starting again.

Any help is appreciated.

EDIT:

When I type "which django-admin.py" it uses the one inside the virtualenv. When I install with "pip install -I Django==1.8.2" it downloads the right one, but then installs the wrong one.

Here's some more output from the command line:

(blog_test)[pattmayne@web476 blog_test]$ pip install -I Django==1.8.2
Collecting Django==1.8.2
  Using cached Django-1.8.2-py2.py3-none-any.whl
Installing collected packages: Django
Successfully installed Django-1.7.8
(blog_test)[pattmayne@web476 blog_test]$ which django-admin.py
~/bin/django-admin.py
(blog_test)[pattmayne@web476 blog_test]$ django-admin.py --version
1.7.8
(blog_test)[pattmayne@web476 blog_test]$ bin/django-admin.py --version
-bash: bin/django-admin.py: Permission denied
(blog_test)[pattmayne@web476 blog_test]$

It's using something from a cache. I'll keep messing around, but any insight is still appreciated!

Matt Payne
  • 198
  • 4
  • 15
  • Is django installed in your system Python? – kylieCatt Jun 04 '15 at 15:51
  • 1
    And `pip install -I Django==1.8.2` doesn't fix this? – Martijn Pieters Jun 04 '15 at 15:51
  • @Martijin I think that worked! Now how do I change the active version? When I enter django-admin.py --version it still says "1.7.8" – Matt Payne Jun 04 '15 at 15:59
  • @MattPayne: are you using `django-admin.py` *installed in the virtual env*? – Martijn Pieters Jun 04 '15 at 16:02
  • @IanAuld Yes, it is. Shouldn't that be irrelevant when I'm using virtualenv? I thought that's why we used virtualenv. – Matt Payne Jun 04 '15 at 16:02
  • @Martijin I used "source bin/activate", so I was under the impression that I was using the virtual env version of django-admin. How can I know for sure? – Matt Payne Jun 04 '15 at 16:04
  • 1
    @MattPayne: `head \`which django-admin\`` should tell you what interpreter will be used. It'll almost certainly be the wrong Python version. – Martijn Pieters Jun 04 '15 at 16:17
  • @MattPayne I ask because your install info you posted isn't installing anything, it's letting you know it found a previous version and is skipping the install. What does `which python` output? – kylieCatt Jun 04 '15 at 16:33
  • @Martijin Pieters It's saying ~bin/django-admin.py which I'm pretty sure is the local virtualenv version. But now I see that even with "install -I" it's downloading the correct version but installing the old one (see the edit I posted above) PS thanks for sticking with this so far. – Matt Payne Jun 04 '15 at 18:55
  • Do you have system site packages enabled for your Virtualenv? If so, I would suggest turning it off. It tends to break things. – Kevin Jun 04 '15 at 18:56
  • @Kevin I used "--no-site-packages" is that enough? Or is there a different way to do it? – Matt Payne Jun 04 '15 at 19:01
  • That should be fine (though the "correct" way is to pass no options and let it default to no site packages). I'm stumped. – Kevin Jun 04 '15 at 19:03
  • Isn't `django-admin.py` the wrong command now? I thought they switched it to just `django-admin`, can you try running that instead? See if there's a binary without the `.py` extension at the end? – Nitzle Jun 04 '15 at 21:20
  • I just ran into a similar problem while trying to upgrade Django from 1.6.2 to 1.7.10. I kept getting 1.6.11 instead. I discovered that the version of django-debug-toolbar I had pinned my install to wouldn't work with anything higher than 1.6.x so it was downgrading my Django version to 1.6.11. This is something else to watch out for. – Jim Sep 12 '15 at 20:52

1 Answers1

0

The problem is that WebFaction has a system-wide site customization policy that injects $HOME/lib/pythonX.Y into your Python search path. This was put into place many years ago, before virtualenv was widely used. For some reason, virtualenv can't seem to ignore a system-wide policy like this.

The solution is to override the system policy by creating an empty sitecustomize.py in your virtualenv's lib/pythonX.Y directory, eg:

touch /home/you/path/to/virtualenv/lib/pythonX.Y/sitecustomize.py

Then reactivate your virtualenv.

Sean F
  • 817
  • 9
  • 20