>> 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
_______________________________________________
Tutor maillist - Tutor@python.org
To unsubscribe or change subscription options:
http://mail.python.org/mailman/listinfo/tutor
