On Sep 12, 10:06 am, "Matt Conrad" <[EMAIL PROTECTED]> wrote:
> On Fri, Sep 12, 2008 at 11:15 AM, Jeff Anderson
>
> <[EMAIL PROTECTED]> wrote:
> > You can influence what this list is, by setting the PYTHONPATH
> > environmental variable. All you need to do is set your PYTHONPATH
> > appropriately, and point it to the appropriate place, depending on which
> > Django installation you need to use. Anything in the PYTHONPATH
> > environmental variable is put at the beginning of sys.path in the python
> > interpretor.
>
> > You can't just rename the django directory and expect it to work-- it won't.
>
> Thanks for the PYTHONPATH tutorial. I notice that
> \site-packages\django is not explicitly listed, though other
> subdirectories of \site-packages are. I assume that there is an
> implied search of subdirectories w/ PYTHONPATH and that is why Django
> still runs.
>
> If I understand correctly then, I would want to rename my 0.96 django
> directory to "django096", move it OUT of sitepackages so it isn't
> found accidentally, install django version 1.0. Now I have \django
> (1.0) under sitepackages and 0.96 elsewhere. Using a "from django"
> import statement will give me 1.0 as default.
>
> If I wanted to use 0.96 instead, I would need to set my PYTHONPATH env
> var to the copied \django096 directory. When I start Python/Django,
> this directory would be inserted at the beginning of the sys.path
> list, so Python would now use \django096 preferentially to
> \site-packages\django, giving me v0.96 behavior. My import statements
> would still be "from django" and not "from django096".
>
> Because all of the django imports will be detected first in the
> \django096 directory, using "from django" will not burn me, even with
> the nested import statements that Steve Holden was talking about. (I
> could imagine other reasons to get burned, but you say this has worked
> well for you in the past, so I'm assuming they don't happen.)
>
> Do I have the above correct?
>
> Matt
The site-packages directory is an implicit location that is built into
every Python interpreter (for better or worse). It makes it easy to
get started with Python without needing to have an approach for
managing sys.path, but as you've encountered you'll need to change
your approach as soon as you want two use two different versions of
the same library. Personally, I've put stuff into site-packages and
then spent *waaay* too much time banging my head wondering why older
versions of a library are being used - a silly mistake, but one I've
made even after even after using Python for many years. Ideally you
only want to have very stable, unchanging libraries in site-packages,
such as database adapters or PIL.
You can add additional implicit locations to sys.path by adding files
the site-packages directory that end in .pth that specify additional
locations, which is why you are seeing additional directories within
sys.path. When doing an import, Python will recurse into any directory
that has a '__init__.py' file (this can be zero-byte file, it's
existance just marks a directory as a Python package).
With VirtualEnv you are basically "cloning" your Python installation,
so that you get a virtual site-packages directory. The "real" site-
packages might have your database adapter libraries installed there,
then one virtual python would have a site-packages/django with version
1.0 and another virtual python would have a site-python/django with
version 0.96. You can achieve the same effect though by just putting
two django installs somewhere on your system, and then fiddle with
your PYTHONPATH environment variable to point to the desired version.
Finally, you could patch a Python program such as manage.py so that
you do something like:
import sys
sys.path[0:0] = [
'\somelocation-for-django-1.0\',
]
import django
This would pick up your Django 1.0 install explicitly without relying
on setting the PYTHONPATH (since setting the PYTHONPATH can effect
imports for any Python program run under a user account). Of course,
hand-patching your Python scripts in this manner is incredibly lame,
however tools such as zc.buildout can be used to manage all of the
hard-coding necessary for an explicit, declarative install so it's not
necessary to get your hands dirty with such things ... in this way you
can use a single Python installation and use as many versions of
Django or other libraries side-by-side cleanly. This is the approach
that Zope migrated to over the last couple of years, and as someone
who manages many, many Zope apps (both development environments on my
workstation and production environments on the server), I've shot
myself in the foot *far, far* less with this approach than all of the
other techniques which I used previously - it's very nice :)
However, using zc.buildout with Django is still experimental, so I
can't recommend it in your case (I'm not currently using it w/ Django
- but there are some folks are trying this approach).
--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google Groups
"Django users" group.
To post to this group, send email to django-users@googlegroups.com
To unsubscribe from this group, send email to [EMAIL PROTECTED]
For more options, visit this group at
http://groups.google.com/group/django-users?hl=en
-~----------~----~----~----~------~----~------~--~---
