saved sys.path

[Eric S. Johansson]

Alex Martelli wrote:
> I agree.  But putting it in a scriptfile instead of a datafile is just
> as good, IMHO -- just like, say, config info for my bash shell sessions
> goes into a file .bashrc which is a script rather than being just a
> datafile.  Most of what .bashrc does is setting environment variables,
> but the extra flexibility of it being a script may still help.

agreed to a point.  What makes me uncomfortable about configuration 
files like .mumblerc files is what happens to them over time.  That this 
is not a python specific problem and it may just be a quirk of my 
personality.

over time, the base knowledge underlying configuration files changes and 
manual handling of those configuration files on every update should not 
be a requirement.  automatically updating files which are scripts as 
well as configuration data is much more difficult than just 
configuration files alone.

Another irritation is that if I set up configuration files to create a 
particular environment on one machine, replicating the machine 
independent portions of those configuration files and keeping everything 
else up-to-date spread across a 10 or 15 other machines is quite a pain. 
    it really could be handled better.  Not quite sure how yet but I'm 
thinking about it.  The solution is starting to smell like starter kit 
and Web server containing machine specific and independent configuration 
information.


> Similarly, as I see things, config info for a big app (coded in Python,
> or in whatever other language as long as it's got a Python accessible
> interface) can be in a scriptfile instead of a datafile.  The scriptfile
> starts up, adjusts environment info (sys.path foremost, but maybe other
> stuff too), imports the app's main module, launches 'main(sys.argv)'
> therein.  It _is_ externalized from the program, in my view -- it's a
> configuration scriptfile.  It just works better, with Python, to have
> the configuration scriptfile call the app's main, rather than doing it
> the other way round as you would in, say, C (where the app's main starts
> and then calls a configuration scriptfile).

so let me see if I understand.  If a application has X commands, there 
are X script files which set up the appropriate environments and call 
the individual command mainline routines?

it would probably help me if you could point me at an example of which 
you would consider a good version of this environment.

> I do like what you've posted, don't get me wrong -- I'm just pointing
> out that our different preferences on app configuration architectures do
> not descend from differences on the "externalized from the program"
> philosophy!

thank you.  It could probably be included into site.py without too much 
trouble if there was any interest.  I've been meaning to submit for 
consideration a couple things including a version of smtpd.py that forks 
off child processes and a file based queue system.  But I fear this 
conversation would start heading in the direction of the cpyan thread.  :-)

---eric