Hi Bill, thank you very much for the additional advice, and for the book references - especially the latter where you pre-empted my question.
As you say I have come to Django without devoting much effort to the important Python aspects, and I have realised in the past month or so that I made a huge mistake. Hopefully in the coming weeks I can redress that. Thanks again. Mauro On 20 Jan, 16:25, Bill Freeman <ke1g...@gmail.com> wrote: > 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.
