[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