Eric S. Johansson
esj at harvee.org
Wed Nov 3 12:53:18 CET 2004
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
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
> 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"
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. :-)
More information about the Python-list