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.
> > 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?
> > 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.
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?
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.
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
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.
Just more fuel for the fire, ;-)
-Chuck
_______________________________________________
Webware-devel mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/webware-devel
