On Tue, Jan 19, 2010 at 7:57 PM, MauroCam <maurociac...@gmail.com> wrote:
> Bill,
>
> thanks for all your help. I have fixed it by manually saving
> PYTHONPATH in.profile, and the sys.path is now reflecting the correct
> path. Runnnig the loaddata command now correctly loads the data!
>
> Not sure why saving it in .bashrc did not have the same effect.
>
> Will also try your suggestions, as I do need to get both LIVE and TEST
> working.
>
> Could not have done it without you!
>
> Mauro
I'm glad that it has worked out.
If the passing of this crisis gives you some time, I have some
suggestions for your
leisure reading list.
These were python problems, not django problems. If you are using a
python based
framework like django, it's always worth sharpening your python
skills. If you're not
already familiar with python, it is a useful language for projects
large (e.g.; django,
plone/zope) and small (e.g.; the one liner I did last week to convert
someone's UTF-16
file to UTF-8) and available on most platforms (even on my Nokia 810).
The tutorial at
python.org is well worth the hour that it will likely take you. There
are links to the on
line documentation there as well. My favorite book is the Python
Essential Reference,
by Beazley, but it is, indeed, a reference. Some of the more beginner
focused books
like Learning Python (was that Mark Lutz?) are more likely to spend
time discussing
the way to set up the environment, but may be slightly dated in terms
of the favored
approaches today (how recently update?), and everything really is
available on line.
If you expect to want multiple projects to run in environments with
different python
configurations (sets of installed packages) on a single accout, you
owe it to yourself
to investigate virtualenv. It doesn't do anything that you couldn't
do yourself, including
by hand, but that's true of much of the software we use, and, of
course, virtualenv is
free, open source software.
Issues with where to put environment variable setting stuff can be
confusing, even
for folks who primarily use *nix systems. The first thing to confirm
is you are using
bash. That's typically the default on linux systems, but even the
default is up to the
sysadmin, and users can typically change the shell used for their
account. csh, fior
example, is not going to read .bashrc. If a variable is set in two
files, the one that
gets read last wins. For example, a login shell reads your .bash_profile (or
.bash_login or .profile, which ever it finds first, but only on of
them) instead of reading
.bashrc. Sub-shells (if you, for example, type "bash" at the bash
prompt, or type
commands inside parentheses) reads .bashrc, but not the others. But on most
systmems (in my experience) your .bash_profile is set up so that the
first thing that
it does is explicitly read .bashrc. In that case, it's as though
.bashrc is always read
first, followed by, if it is a login shell, (the rest of)
.bash_profile. So for settings that
occur both in .bashrc and (later) in .bash_profile, the .bash_profile
settings will win
in login shells, and the .bashrc settings will win in subshells. It
is customary to
initialize inheritable things like enviorment variables, including
PATH, in .bash_profile,
because subshells obtain them from their parent via "the environment".*
But realize that bash only reads these files when it starts up (or if
explicity told to
read them with the source command), so to test a change in .bash_profile (or
.bash_login or .profile, whichever you have), you must log out and log back in.
One thing to specifically concern you is that if you have a .profile,
and you don't
have a .bash_profile or .bash_login, and the .profile file doesn't
explicitly source
.bashrc (and ti really shouldn't since .profile is read by some other
shells), then
your .bashrc settings don't affect your login shell. That could be
why you didn't
see the changes that you made there. If so, then you might consider adding the
following .bash_profile file:
----------------------------
# .bash_profile
# Get the aliases and functions
if [ -f ~/.bashrc ]; then
. ~/.bashrc
fi
# Get the common login settings
if [ -f ~/.profile ]; then
. ~/.profile
fi
# Put login settings only to be used by bash below.
---------------------------
(The "." that is the first non-blank in the middle of each if is an
alias for the "source" command.)
[ * There is, however, a hazard to putting much stuff in *profile
files. If you use ssh (or in ancient
times, rsh) or, I believe, xon, to run a single command and exit,
rather than to get an interactive
prompt, then sshd (or equivalent) starts the shell that runs the
command as a non-login, shell,
that is, a subshell, so your profile files are not used. Generally
that's what you want, but, for
example, I tend to use mercurial with ssh:// style urls to move things
up to, for example, a server
at a webhosting company. Often mercurial isn't' installed by default,
but I can add it to my account's
bin directory, and use .bash_profile to add $HOME/bin to the PATH.
But when mercurial attempts
to access the account remotely, .bash_profile isn't run, and it can't
invoke a partner mercurial on
the server with which to communicate. I get around this by putting my
PATH adjustments in .bashrc.
That's a minor issue in sub-shells, since my bin directory gets added
twice. For the fastidious (like
me) it is easy enough to use a flag environment variable to only add it once. ]
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.
