On Tue, Jan 19, 2010 at 4:57 PM, MauroCam <maurociac...@gmail.com> wrote:
>
>> pprint.pprint(sys.path)
> - LIVE & TEST both return the same as I'd expect. Not sure if /home/
> test-project/src should be in there though, and if it should not be /
> home/project/src:
> ['/home/projectt/src/projectfiles ',
> '/home/test-project/src',
> {lots of python 2.5 folders}
> '..']
>
>> import django
>> django
> LIVE & TEST return: <module 'django' from '/home/test-project/src/
> django/__init__.pyc'>
>
> ****** I would have expected this to be '/home/project/src/django/
> __init__.pyc' *****
>
> In addition I also ran the following
>
> -----------
> import settings
> settings.DATABASE_NAME = value in settings.py file that defines the DB
> - LIVE returns: DBLIVE
> - TEST returns DBTEST
>
> So I am quite confused because
> a) we deployed the Django source to both TEST and LIVE in order to
> keep them separate for testing purposes
> b) it looks like we are instead running the "wrong" copy of the django
> source. So how do I change that? And once I change it, does it mean I
> will not be able to run a separate loaddata.py for TEST?
> c) is the correct setting returned above ovewritten by where the
> django code being executed?
>
Well, if sys.path is the same for both, they are both going to load
the same django.
The exception to this is that, at least when python starts, the first
item o the path is
an empty string, representing the relative path to the current
directory (at startup),
which, I believe, has been replaced by an absolute path to the same directory by
the time manage.py gets moving. I would really hope that this
difference is reflected
in sys.path's first entry (or that it is still an empty string).
Since you summarize
rather than paste that output, I can't check for you.
Still, since the settings file is being imported appropriately, as
evidenced by the
difference in the database name, I'm pretty sure that this must be the case.
[BTW, the "correct" way to examine the settings from the manage.py
shell, or from
within any of the .py files in your project, is:
--------------
from django.conf import settings
settings.DATABASE_NAME
------------------
]
When you say deployed the django source, I'm guessing that you mean unpacked the
egg or tar or zip there. But how are you arranging for python to find
it? When you
install django in the default way, it usually goes somewhere like:
/usr/lib/python2.6/site-packages/
Which python searches by default (you should see a site-packages
directory one or more
times in your sys.path).
So, for it to have found django in /home/test-project/src/ that path
would have had to be
added to sys.path somehow. This can't be in your settings.py because manage.py
imports django (part of importing django.core.management, if you look
at manage.py in
an editor) before it imports settings. So, either you have a modified
manage.py that
fiddles with sys.path first, or you have a strangely configured
python, or, more likely,
you have the PYTHONPATH environment variable configure to do this,
since python checks
for this and adjusts the path up front if it finds it.
If it is the environment variable, it is probably set in your
.profile, .bashrc, .bash_profile, or
.bash_login files. (Use "ls -a" to see these "hidden" files - those
whose name begins with
a period - if they are present.)
If it's the environment variable, you can:
Change it by hand before running a particular version
Have two separate users for the two separate versions, having
different environment variables
Have a bash script in each folder that you use instead of "python
manage.py" which sets the
variable, then runs python manage.py along with the rest of the
arguments you supplied.
Modify your manage.py scripts to manipulate sys.path before
importing anything else.
Or investigate and deploy the virtualenv tool.
The last is my favorite, though you still have to remember to
"activate" the appropriate environment,
so I tend to use a combination of that with a shell script named
manage that does the activation
(local to itself) and then invokes manage.py. I cd to the appropriate
directory and run, for example,
./manage loaddata
Good luck. Bill
--
You received this message because you are subscribed to the Google Groups
"Django users" group.
To post to this group, send email to django-us...@googlegroups.com.
To unsubscribe from this group, send email to
django-users+unsubscr...@googlegroups.com.
For more options, visit this group at
http://groups.google.com/group/django-users?hl=en.
