On Friday 07 December 2001 13:34, Chuck Esterbrook wrote:
> On Friday 07 December 2001 12:43 pm, Tavis Rudd wrote:
> > The scheme we were talking about yesterday would allow the end
> > user to make the choice of whether to go for a single file or
> > split it up. To Webware and its components it would be
> > transparent. I think option 2 or 3 should be the default layout,
> > as a Webware componenent shouldn't meddle with another components
> > configs.
>
> Then why bother with 1? For someone anxious to get rid of
> supporting dicts because it's extra cruft, it seems strange to put
> so much weight on the value of a monolithic config file.
> Particularly if it's not the default and not many people will use
> it.
Ok, scrap 1 and point taking about my cruft fallacy. But the example
was meant to illustrate that this scheme would use exactly the same
logic to load settings from all of those layouts.
> > > What's the __init__.py for? In other projects I just went with:
> > > Configs/
> > > FooBar.config
> > >
> > >
> > > and did an exec on FooBar to get the variables which looked
> > > like:
> > >
> > > reps = 50
> > > names = 'foo bar'.split()
> >
> > The idea is to import the 'WebwareConfig' package so that all
> > import statements inside it will work properly without needing to
> > manipulate sys.path. Exec makes me go 'ick', when you could just
> > to an import.
>
> I wasn't imagining an import statement (other than os, sys, etc.
> for special situations) in a config file. In any case, I guess
> import over exec works just as well except for the __init__.py
> requirement. I'm 50/50 right now.
> > > We definitely have to be able to distinguish the file as
> > > install.py does things with config files (which will change in
> > > nature in the future, but still be a requirement).
> >
> > That brings up the issue of what should it be doing to the config
> > files? There have been fairly unanimous calls for the core
> > classes to be installed in a completely separate location from
> > user files via distutils.
>
> Right now it backs them up so you can refer to the original values.
> In the future, it will reverse that. eg., copy *.default.config to
> *.config for reasons that we discussed earlier.
> > But what about the config files? Do they also get installed to
> > the same place as the core packages or are they something the
> > user must install? I'd argue for installing a template of the
> > configs to the central location and then requiring the users to
> > 'check out' a copy they can modify locally ---> "<prompt>
> > webware install-configs" or something like that would copy the
> > templates to the current directory for the user to modify.
>
> I believe that MakeAppWorkDir, which was patched in by Robin Dunn,
> already does this today. I think it also takes advantage of
> *.config.
>
> Have you ever used it?
I've read the code and ran it once. The idea is the same, but I'd
implement it a little differently to work well with the distutils
framework.
> > > The plan I was changing for Configurable was simply to do an
> > > exec, unless the first char was a {, in which case I would do
> > > an eval.
> >
> > What do you think about the syntax that Geoff proposed as an
> > alternative to dictionaries? They're compatible, but I prefer
> > the class syntax.
>
> I must have missed that message, so I don't know.
>
> In general, I strongly prefer Python over any custom config syntax.
The syntax he proposed is pure Python.
> On Thursday 06 December 2001 03:34 pm, Tavis Rudd wrote:
> > We'd need to provide an interface to get at the settings as the
> > import statements wouldn't always work as expected, but that's no
> > big deal.
>
> Er, why? foo.bar.baz wouldn't work in your scenario?
foo.bar.baz would work, but not necessarily "from foo.bar import baz"
I was thinking more along the lines of:
from WebwareConfig import getSettings
theSettingsINeed = getSettings('WebKit.AppServer')
That would accomodate having a single config file for WebKit or
multiple files.
> I like asking self for settings, btw. This allows classes and
> individual objects to partake in their configuration if needed. I
> have taken advantage of this when I needed to.
I see your point, but think it's best not to bind classes to a
particular scheme for finding configs on the file system. They
should be able to do it when absolutely needed, but it shouldn't be
part of their __init__ process. Doing so makes it harder to use them
in situation beyond what the author intended. That's why I prefer
the FacadePattern (http://c2.com/cgi/wiki?FacadePattern), in which
you use a launcher class to collect the relevant settings and feed
them to the various classes involved. It's more flexible.
> BTW One issue with configuration is making the command line stuff
> come in correctly. eg, if you allow individual config settings to
> be passed on the command line like so:
>
> foo.py iters=50
Hmm, you could use SettingsManager for that. It can recognize
strings that represent numbers (even complex nums) plus
booleans(true/false) convert them to the appropriate Python value.
You feed it a dictionary with string values and it will spit out a
translated version of the dict. It also understands python literals
like lists, etc. if you preface the string with "python: "
foo.py iters=50 list="python: [1,2,3]"
> Then iters comes in as a string instead of an int unless you go out
> of your way to do something about it. I handled this on one project
> by actual defining my config file settings: name, type,
> description, synonyms, etc. I used the description to generate
> docs. I used the type make sure things came in right from the
> command line and type check what was brought in via Python.
> Also, I find it just as important if not more so in my various
> projects to be able to tweak one setting on the command line, as I
> do to point to a whole new config file.
Good point. Have a look at the new command line interface to Cheetah
template modules that Mike and I added last night:
http://cvs.sourceforge.net/cgi-bin/viewcvs.cgi/cheetahtemplate/Cheetah/src/TemplateCmdLineIface.py?rev=1.4&content-type=text/vnd.viewcvs-markup
It accepts os.environ or pickled objects as things to place at the
beginning of the searchList and override $placeholder defaults.
|