Cliff Wells wrote:
> On Wed, 2006-03-08 at 12:11 -0500, Kevin Dangoor wrote:
> > So, taking into account the various bits of input and the fact that
> > there would appear to be a problem with the new style configs and
> > Python 2.3, I'm going to change our config system over to using
> > ConfigObj.
> >
> > http://www.voidspace.org.uk/python/configobj.html
>
> Only looking briefly, this looks like an extension of an .ini file, i.e.
> not a Python file. I think this is bad. ini files offer nothing over
> Python configs and in fact quite a bit less. As an example, say you
> have a database password with the character '@' in it (as so many do).
> You can't pass this as part of a URI without encoding it. With a Python
> config you can do that as part of the URI declaration. With an ini
> you'll need to encode it elsewhere and copy/paste it into your config.
> This is just one example that would be an immediate annoyance for me.
> I'm sure there are others.
>
There is a way of doing this with ConfigObj - using the validator.
Validation allows you to check that a config file meets a certain
specification - e.g. checking that values are present, providing
default values if you want, and checking that values make sense, e.g.
can be converted to an integer etc.
Validation *also* transforms values, into integers, floats, booleans
etc. (And can check parameter bounds if you want.)
You can easily extend validation to use any transformation function you
want. You then specify in the configspec which check (function) to use
for each value. You *don't* need to specify a check for every value,
just the ones you want checked.
I'll give you a concrete example :
# config file
[section]
key1 = True
key2 = 3
key3 = 3.0
key4 = 'value which needs to be url escaped %@'
key5 = unchecked
# configspec
[section]
key1 = boolean
key2 = integer
key3 = float
key4 = url_escape
key6 = integer(default=3)
Note a few things. key5 does not have an entry in the configspec. Also,
the standard validator doesn't have a check called 'url_escape'. key6
in the configspec supplies a default value if it isn't present in the
config file.
Using the configspec to validate the config file :
from validate import Validator, VdtValueError
from urllib import quote_plus
from configobj import ConfigObj
def url_escape(value):
try:
return quote_plus(value)
except: # can this raise an error ?
raise VdtValueError
functions = {'url_escape': url_escape}
vdt = Validator(functions)
cfg = ConfigObj(filename, configspec = cfgspec_filename)
cfg.validate(vdt)
for key, value in cfg['section'].items():
print key, ':', value
Output :
key1 : True
key2 : 3
key3 : 3.0
key4 : value+which+needs+to+be+url+escaped+%25%40
key5 : unchecked
key6 : 3
(Order retained in output)
The ``cfg.validate`` call returns either ``True`` (validation
succeeded) or a dictionary of failed values and error messgaes. (See
the documentation for the format of this.) You can use the
``flatten_errors`` function to turn this into a list of errors.
So you *could* allow the application developer to provide a custom
validator and configspec. Values in the config file can be munged in
any way you please. This may not be appropriate - but it's an option.
(It does however keep these transformations out of the config file
itself, which is more appropriate IMHO.)
If you have any issues arising with ConfigObj, or feature requests,
then feel free to contact me.
Michael Foord
http://www.voidspace.org.uk/python/index.shtml
> Basically using ini restricts you from calculating values within the
> config which I consider needlessly restrictive.
>
> Perhaps we could have a compromise: I see from the docs that you can
> programmatically write a config file from ConfigObj rather easily.
> Maybe start-project.py could check if the passed config file is a .py
> file and if so, assume that it will generate the appropriate config on
> the fly (so that 'start-project.py devcfg.py' would generate devcfg.ini
> which would then be used).
>
> Regards,
> Cliff
>
>
> >
> > This returns the format to the same as CherryPy's, but has additional
> > benefits. A key part of the TG 0.9 configuration change is that the
> > configuration is split into two files: application config (which lives
> > in your project's package) and deployment config. So, here's what I'm
> > proposing:
> >
> > 1) path() changes back to []
> > 2) absfile() will change to some variable you can substitute in using
> > the %()s style that points to the absolute path of your project's
> > package.
> > 3) both config files go back to having .cfg extensions
> >
> > I'm also considering adding a config directory and breaking up the
> > configuration into separate files so that they don't become unwieldy.
> > I think there's going to be a lot more configuration possible (but not
> > required) in the future.
> >
> > I think that's about the extent of the user-visible part of the change.
> >
> > This change will also make moving to First Class easier.
> >
> > Kevin
> >
> > --
> > Kevin Dangoor
> > Author of the Zesty News RSS newsreader
> >
> > email: [EMAIL PROTECTED]
> > company: http://www.BlazingThings.com
> > blog: http://www.BlueSkyOnMars.com
> >
> >
> --
--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google Groups
"TurboGears" group.
To post to this group, send email to [email protected]
To unsubscribe from this group, send email to [EMAIL PROTECTED]
For more options, visit this group at http://groups.google.com/group/turbogears
-~----------~----~----~----~------~----~------~--~---
