[bzrweb PATCH] look up repository descriptions in a config file
John A Meinel
john at arbash-meinel.com
Sat May 21 19:13:59 BST 2005
Chris McCormick wrote:
> On Fri, May 20, 2005 at 09:35:24AM -0400, Sean Russell wrote:
>
>>The provided example is an excellent reason why XML should be considered for
>>this. I can easily imagine, six months from now, a proposal to add more
>>information to the <author> section:
>>
>> <treedescription>
>> ...
>> <author>
>> <email>...</email>
>> <web>...</web>
>> </author>
>> </treedescription>
>>
>>Using XML will guarantee extensibility, and provides the ability to store
>>hierarchical structure.
>
>
> I agree that it's pointless having religious wars about what config
> file format is best, but I do think that if you have to edit a config
> file a lot by hand it is nice to have one that is easy to parse with the
> human eye. That said, I don't want to make flames, so it's as a purely
> academic exercise and with no hidden motives that I propose a method
> for using ConfigParser in a manner that is extensible in a way that is
> similar to an XML file:
>
> ---------------------------------------
> [treedescription]
> author: *myauthor
> foo: bar
> pants: 100
>
> [myauthor]
> email: dude at dudeland.org
> web: http://awesomedude.org/
> ---------------------------------------
>
> So your config parser instance would do something like this:
>
> author = cfg.get("treedescription", "author")
> if author[0] == "*":
> authbits = cfg.options(author[1:])
>
> You could easily write a superclass of ConfigParser that handled this
> style of referencing elegantly.
Well, ConfigParser already supports python variables, so you can do:
[DEFAULT]
var: abcd
path: /root/to/here
[author]
email: %(var)s other stuff
[project]
basepath: %(path)s/project
bzrpath: %(basepath)s/.bzr
I forget the exact syntax.
But honestly, I think the * format doesn't work really well, since you
have to know that there will be extra information.
If I am looking for "author", then I should expect to find the extra
information. For instance:
[treedescription]
author: myname
author-email: dude at dudeland.org
Otherwise, how does the front end know to handle [myauthor] entries? Are
they concatenated together, should they be excluded if unknown? Etc.
I'm also curious about the other config parser is it cfgparse? Anyway,
it seems to have read/write support *and* it keeps track of comments,
which is very nice.
I don't think XML is any more extendable than anything else. You still
have to define a schema that can be parsed, and make a
forwards/backwards upgrades to it. An old client which could read:
<author>Dude Man</author>
Isn't going to understand
<author><name>Dude Man</name><email>dude at dudeland.org</email></author>
It just depends how you want to handle forward-compatibility. You could
have a fully self-describing config file, so that you know what tags are
optional (thrown away), and what tags are required (it is an error if
you don't understand them/if they are missing).
But that is quite a bit of overhead for a config file. I would argue for
a standard .ini style, with a mandatory version number, so whatever
changes with time can still be parsed.
John
=:->
>
> Another example; later if you wanted to make 'web' more complicated your
> entry would look like:
>
> ---------------------------------------
> ...
> [author]
> email: dude at dudeland.org
> web: *myweb
>
> [myweb]
> http: http://awesomedude.org/
> rss: http://awesomedude.org/blah/rss/
> ---------------------------------------
>
> On the other hand, you present many other good reasons to use XML, even
> if some people do find it annoying to edit by hand. I guess it comes
> down to how people are going to edit the config files and what their
> preference is.
>
> Best regards,
>
> Chris.
>
> -------------------
> chris at mccormick.cx
> http://mccormick.cx
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 251 bytes
Desc: OpenPGP digital signature
Url : https://lists.ubuntu.com/archives/bazaar/attachments/20050521/e4d6ced6/attachment.pgp
More information about the bazaar
mailing list