Forums

• [Admin note] see our wiki page about using specific versions of Django inside virtualenvs

I installed Django 1.4 by following the advice in the 'Installing Django 1.4' thread. Which has worked fine and made uploading new stuff from my computer much less of a headache.

Unfortunately, I've made a few big leaps forward on my home machine and that involved changing models.py. So I installed something called django-evolution using easy_install and ran ./manage.py syncdb.

It fails with the same errors it used to give before I switched to 1.4, making me think that the console is still somehow using 1.3. How do I change that? Also, does this mean I went and installed django-evolution in the wrong place?

If you used a vitualenv to run Django in your web app, you need to switch to the virtualenv in the console so you use the right Python and installed packages. You'll need to do this for installing django-evolution and for running:

workon <virtualenv with Django 1.4>

"bash: workon: command not found"

Also, any way I can find out which virtualenvs I've got?

Got it working using:

source ../Envs/django/bin/activate

Unfortunately now

easy_install -U django_evolution

says it can't find what it's looking for. I tried 'django_evolution', 'django-evolution' and 'djangoevolution' with no luck.

About one time in three, the easy_install script trips out with

"setuptools-0.6c11-py2.7.egg/setuptools/package_index.py", line 475, in fetch_distribution
AttributeError: 'NoneType' object has no attribute 'clone'

Poking about in the Envs/django/bin folder started getting me Permission Errors. (I have no idea what I'm doing.)

EDIT: this also doesn't work, fails in exact same way:

easy_install --allow-hosts=lxml.de,*.python.org lxml

Have I somehow blinded easy_install?

EDIT (2): Not sure what I did, but I can now no longer use easy_install in a fresh console with no virtualenv or anything.

 [Errno 30] Read-only file system: '/usr/local/lib/python2.7/site-packages/test-easy-install-2919.write-test'

I'm going to stop now before I do any more damage. Need food, sleep.

Three things I hope might help:

1) When using virtualenvs, you have to "activate" the virtualenv in any console session, before you use it. For this, you can either use activate, or workon from virtualenvwrapper. If you're not quite sure how these work, find a virtualenv tutorial and work through it until you're 100% comfortable with how it all works.

2) The recommended tool for installing new packages into a virtualenv is pip, not easy_install. In addition, there's no need to use the -U flag. -U (or --user for pip) tries to install packages to your home folder. In a virtualenv, you don't want things in your home folder, you want them in the virtualenv's lib folders, and the virtualenv will take care of making sure that happens, if it's active. So normally, you'd want to just run bin/pip install django-evolution -- bin/pip should make sure you get the virtualenv version of pip...

3) You won't be able to install lxml, because it requires a compiler. You might be able to work around this using the --system-site-pacakges option...

I was able to get everything installed OK into a fresh virtualenv:

$ cd /tmp/
$ source virtualenvwrapper.sh   # i'm using virtualenvwrapper to manage my virtualenvs
$ mkvirtualenv testey

# note - at this point the prompt shows (testey), which means the virtualenv is active
(testey)13:07 /tmp $ which pip  
 /home/harry/.virtualenvs/testey/bin/pip  # pip is now pointing at the virtualenv version
(testey)13:00 /tmp $ pip install django

Downloading/unpacking django
  Downloading Django-1.4.3.tar.gz (7.7MB): 7.7MB downloaded
  Running setup.py egg_info for package django
Installing collected packages: django
  Running setup.py install for django
    changing mode of build/scripts-2.7/django-admin.py from 664 to 775  
    changing mode of /home/harry/.virtualenvs/testey/bin/django-admin.py to 775
Successfully installed django
Cleaning up...

# django is now installed in the virtualenv called testey:
(testey)13:10 /tmp $ ls /home/harry/.virtualenvs/testey/lib/python2.7/site-packages/django
__init__.py  __init__.pyc  bin  conf  contrib  core  db  dispatch  forms  http  middleware  shortcuts  template  templatetags  test  utils  views

(testey)13:05 /tmp $ pip install django-evolution

Downloading/unpacking django-evolution
  Downloading django_evolution-0.6.7.tar.gz (64kB): 64kB downloaded
  Running setup.py egg_info for package django-evolution

Requirement already satisfied (use --upgrade to upgrade): Django>=1.1.1 in /home/harry/.virtualenvs/testey/lib/python2.7/site-packages (from django-evolutio
n)
Installing collected packages: django-evolution
  Running setup.py install for django-evolution

Successfully installed django-evolution
Cleaning up...

(testey)13:12 /tmp $ ls /home/harry/.virtualenvs/testey/lib/python2.7/site-packages/django_evolution
__init__.py   admin.py   builtin_evolutions  diff.py   evolve.py   management  models.pyc    mutations.pyc  signature.pyc  utils.py
__init__.pyc  admin.pyc  db                  diff.pyc  evolve.pyc  models.py   mutations.py  signature.py   tests          utils.pyc

Here's me switching out of the virtualenv and back in again:

(testey)13:12 /tmp $ deactivate

13:14 /tmp $ 
13:14 /tmp $ which pip
/usr/local/bin/pip
13:14 /tmp $ workon testey
(testey)13:14 /tmp $ which pip
/home/harry/.virtualenvs/testey/bin/pip

Finally, if you're in a brand new console, you have to source virtualenvwrapper.sh to get the workon tool to work:

13:15 ~ $ cd /tmp/
13:15 /tmp $ workon testey
bash: workon: command not found
13:16 /tmp $ source virtualenvwrapper.sh 
13:16 /tmp $ workon testey
(testey)13:16 /tmp $

If you don't want to use virtualenvwrapper, you need to manually run the activate script from your virtualenv:

(testey)13:16 /tmp $ deactivate
13:19 /tmp $
13:20 /tmp $ source ~/.virtualenvs/testey/bin/activate
(testey)13:21 /tmp $

Fantastic, thanks. These virtualenv things are quite nifty. I don't really know what I was playing at last night...

Yes, virtualenv is awesome (and I don't use that word lightly). It's especially useful when you're trying to create isolated environments to test application behaviour when dependencies aren't available, or testing against different Python versions.

Here's an official guide to setting up a web app in a virtualenv on PythonAnywhere... being served up from a web app running in a virtualenv on PythonAnywhere:

http://virtualenvdemo.pythonanywhere.com/

This thread does not fully explain how to fix the problem. I just wrote this for my project wiki page, hopefully a sysop can grab it for the howto page.

Getting access to a system package/library

If your bash term defaults to load your environment exit it with deactivate

Run python, and import the library you want, for example

import PIL
PIL.__file__ 
'/usr/local/lib/python2.7/site-packages/PIL/PIL/__init__.pyc'

Copy the path (/usr/local/lib/python2.7/site-packages/PIL/)

Navigate to the virtual env's site-packages folder, for example ~/.virtualenvs/django15/lib/python2.7/site-packages

Use a file editor to create a file named after the desired import with a .pth extension like pil.pth

nano pil.pth

Put (copy) in the path detected earlier

Save the file.

Restart your virtual environment, for example workon django15

Start Python, and re-try the import such as:

$ workon django15

$ python

Python 2.7.3 (default, Mar 5 2013, 16:37:26)

[GCC 4.4.5] on linux2

Type "help", "copyright", "credits" or "license" for more information.

import PIL

PIL.__file__

'/usr/local/lib/python2.7/site-packages/PIL/PIL/__init__.pyc'

EDIT by admin - helped out with the formatting - it looks like markdown and codehilite don't like code blocks in lists (tried both ordered and unordered)

Thanks for that, @rcooke. That's a really useful bit of hacking. We usually suggest that users create virtualenvs with --system-site-packages, but that's a bit messy. Your way is much cleaner.

Note: That python paths point not to the modules themselves, but to their parent directories!

on this page:

http://djangotricks.blogspot.ca/2008/09/note-on-python-paths.html

I just changed my south.pth file to end it at the site-packages folder.

A word of caution with --system-site-packages and virtualenv.

PythonAnywhere has many installed packages that are tested with the current default version of Django (currently 1.3.7 as of this writing). For example, if you are running a VE with Django==1.4.x, many 1.3.x packages and older may not work as advertised. Always test with the package and read the docs for that package.