[IronPython] Saving sys.path

Keith J. Farmer kfarmer at thuban.org
Wed Apr 27 20:31:06 CEST 2005

Actually, it was Michael who brought it up originally, so maybe ask him?  I just butted in.
There is a reason I'm not overly fond of environment variables -- they tend to get onerous to manage, and they don't necessarily propagate to user accounts after the admin sets them, as I discovered last night.  I've switched to using a normal user account on my machine, and discovered I couldn't change the global IRONPYTHON_HOME variable I'd created (my path includes %IRONPYTHON_HOME% as a convenience thing)?  So I switched to admin, changed it there, and switched back to my user.  My user still used the old home for 0.7.2.  I had to go back to admin, open up the PATH variable, not change a thing, and re-close it before my user switched to 0.7.3.  
Bug in XP?  Almost certainly, IMHO (and I love XP).  Ignorable for managing IronPython installations?  Probably not.  I think a better administrative experience would involve minimizing the dependency on environment variables, and given the built-in mechanisms in .NET
In the case of configuring the interpreter, one need not copy the way CPython does it, if it can be argued that IronPython could do it better, by configuring the application rather than the shell.  It'd allow configuration specific to even a version, if needed, and a richer configuration at that.  I'd at least like to see that as an option.
I propose IronPython use .config, and override with Environment Variables


From: users-ironpython.com-bounces at lists.ironpython.com on behalf of Martin Maly
Sent: Wed 4/27/2005 10:20 AM
To: Discussion of IronPython
Subject: RE: [IronPython] Saving sys.path

There are, as far as I can see, three different ways to help in this case and I am looking into implementing all of them very soon, definitely for the next release.


CPython uses environment variables PYTHONSTARTUP and PYTHONPATH to drive the initialization of the interpreter

Also, on initialization, the interpreter executes statement "import site" which is the third way to hook into the initialization process.


As for the environment variables go, there is a question of naming. One possibility is to use the well-known names (PYTHONSTARTUP, PYTHONPATH) and another is to use our own: IRONPYTHONSTARTUP and IRONPYTHONPATH. We prefer the latter (names prefixed with IRON) to avoid conflicts for those of us who use CPython and IronPython on the same machine.


Unless there is strong reason to use the standard names, we will go forward with the IRONPYTHON... ones.


If you feel one way or another, please let us know. For the purpose of the environment variable naming, we are not considering other naming schemes so the choice is either standard names, or IRONPYTHON* ones.


Keith, I think this should provide you with the tools you need for your work, correct? We will try to get this update out even sooner than usual. 

-------------- next part --------------
A non-text attachment was scrubbed...
Name: winmail.dat
Type: application/ms-tnef
Size: 6741 bytes
Desc: not available
URL: <http://mail.python.org/pipermail/ironpython-users/attachments/20050427/6f00277a/attachment.bin>

More information about the Ironpython-users mailing list