[Tutor] Set LD_LIBRARY_PATH and equivalents platform-independently

[Albert-Jan Roskam]

>>  Thanks for your replies. os.putenv() may be easier than os.environ because,
>>  hopefully, it takes care of the OS-specific separators of the values
>>  (";" for Windows, ":" for Linux, others I don't 
> know
> 
> I wouldn't count on it. Support for changing environment variables on the 
> fly is iffy in most languages and is not something I'd ever do lightly.
> 
> The environment is something that usually should be set up when the user logs in 
> to reflect their preferences, its not really polite of a program to try and 
> alter the users environment...

If you put it that way... yes, I now realize that it could be (and in fact is) really annoying if programs do such things. ;-)
I hate programs that nest themselves everywhere in my OS, using resources. RealPlayer used to be notorious in this respect: shell integration, auto-updater, quickstart, icons all over the place, waaah).
 
>>  Then again, this sentence from the Python page is a little worrying:
>>  "*If* the platform supports the putenv() function, ...".
> 
> Not all OS allow changes to the environment variables. Others only allow the 
> value to be a fixed size allocated at startup and if you write more bytes than 
> are already assigned you will overwrite the next value! The OS assumes that this 
> stuff is set up once and not changed.
> 
> putenv() should always be considered a platform specific bit of code.
> 
> 
>>  As an alternative, I used os.chdir to tell the OS where to start
>>  looking for libraries, but somebody on this list (I forgot who)
>>  warned me that this could have nasty side effects.
> 
> Again the user may expect to be in a certain directory so as a minimum you need 
> to change back to where they were when you exit.

Yes, I considered first using oldpath = os.getcwd(), then use os.chdir in a try clause, and os.chdir(oldpath) in a finally clause.

> The normal way to deal with local file locations is to have a resource file 
> that's read when the program starts up - like .vimrc or .emacs
> Then if the file doesn't exist you either create it at install time or use 
> default values and allow the user to override them.

You mean something like a setup.cfg that is read by ConfigParser? The coolest would be if it worked out-of-the-box, but this may be
the next best thing. I want my C libraries and my .py files to live in the same dir (so not in a standard location such as /usr/lib, but in site-packages.

Thank you Alan!

Albert-Jan