«

Hi,

currently I'm trying to create a pgsql backend for the roundup issue
tracker using the mysql backend as a template (is somebody aware of
such a thing? I couldn't find one). The author has written a config.py
as many authors do. From the programmer's perspective this is a satis-
factory solution: he can use his favourite language and put complex
structures into the configuration. From the sysadmin's perspective this
is not so satisfactory: he would prefer a common configuration format
for his system. To please both one would need a serialization format
and api that

- allows the programmer to easily describe the program configuration,
- is manageable by configuration programs for less experienced users,
- is easily readable and writable with text editors

About 3 years ago Brian Ingerson made a proposal
http://www.geocrawler.com/mail/msg.p...365&list=12303
to use YAML for config files. That seems to be a good idea. It would
meet all specs above. Python currently has a ConfigParser for Windows
style .ini files which doesn't seem to be very popular. I have never
seen a Python project using it. What about adding a conf module that
uses YAML formatted files and provides similar convenience for programmers
as 'import config'? It should be part of Python's core distribution
otherwise it wouldn't be widely used. Any comments?

Mit freundlichen Gruessen,

Peter Maas

--
-------------------------------------------------------------------
Peter Maas, M+R Infosysteme, D-52070 Aachen, Hubert-Wienen-Str. 24
Tel +49-241-93878-0 Fax +49-241-93878-20 eMail
-------------------------------------------------------------------

On Thu, 12 Feb 2004 20:28:44 +0100,
Peter Maas <> wrote:
> structures into the configuration. From the sysadmin's perspective this
> is not so satisfactory: he would prefer a common configuration format
> for his system.

I don't believe that assertion. We have whitespace-delimited files (cron,
/etc/hosts), colon-delimited files (passwd, groups), files containing
line-oriented commands (resolv.conf), ones grouped into subsections and ones
that are flat, etc. and everyone manages to survive.

YAML also has the disadvantage of being a complicated format to learn -- it
may be only slightly simpler than reStructured Text -- and it's not quite
like any other format; it borrows features from Unix-style config files,
Python, XML, and RFC 2822, but it doesn't look like any of them. A "yamlwf"
program similar to Expat's "xmlwf" would help, but is insufficient because
not only must the syntax be correct, the data structure contained in the
YAML file has to match what the application expects.

A good feature of using Python for some applications is that you can then
provide alternatives such as:

if socket.gethostname() == 'devel':
MAIL_EXCEPTIONS = False
LOG_LEVEL = 'debug'
else:
MAIL_EXCEPTIONS = False
LOG_LEVEL = 'warn'

This is messier in a declarative format.

--amk

A.M. Kuchling wrote:
>>structures into the configuration. From the sysadmin's perspective this
>>is not so satisfactory: he would prefer a common configuration format
>>for his system.
>
> I don't believe that assertion.

Belief is not debatable

> We have whitespace-delimited files (cron,
> /etc/hosts), colon-delimited files (passwd, groups), files containing
> line-oriented commands (resolv.conf), ones grouped into subsections and ones
> that are flat, etc. and everyone manages to survive.

Easyness and fun is more than surviving. The files you mention
are linux system files. To create a unified config format for
linux/unix is a task that Python can't handle. I speak only of
application configurations.

> YAML also has the disadvantage of being a complicated format to learn

YAML isn't as verbose as XML, good for editor users. Config files
should need only a YAML subset: strings, numbers, dates, lists,
dictionaries. This seems to be fairly easy.

> it borrows features from Unix-style config files,
> Python, XML, and RFC 2822, but it doesn't look like any of them

Which UNIX style? Anyway, it shouldn't look like Python because
Perl programmers and non-programmers should also be happy with it.

> A good feature of using Python for some applications is that you can then
> provide alternatives such as:
>
> if socket.gethostname() == 'devel':
> MAIL_EXCEPTIONS = False
> LOG_LEVEL = 'debug'
> else:
> MAIL_EXCEPTIONS = False
> LOG_LEVEL = 'warn'
>
> This is messier in a declarative format.

A configuration file should contain a set of mutually independent
variables describing the state of the installed application. This
is not messy. I see mixing of state and logic as a conceptual
disadvantage. It makes life easy for the programmer but not for
the users who sometimes happen to be non-programmers.

Knowing the source is mostly fine but *having* to know the source all
the time is not so fine. Not every language is as friendly as Python.

Mit freundlichen Gruessen,

Peter Maas

--
-------------------------------------------------------------------
Peter Maas, M+R Infosysteme, D-52070 Aachen, Hubert-Wienen-Str. 24
Tel +49-241-93878-0 Fax +49-241-93878-20 eMail
-------------------------------------------------------------------

On Fri, 13 Feb 2004 12:53:23 +0100,
Peter Maas <> wrote:
> A configuration file should contain a set of mutually independent
> variables describing the state of the installed application. This
> is not messy. I see mixing of state and logic as a conceptual
> disadvantage. It makes life easy for the programmer but not for
> the users who sometimes happen to be non-programmers.

Non-programmers don't edit configuration files, though; they use a GUI that
presents a nice interface, and never see whatever format the settings are
stored in. For example, Apple's property lists provide more or less the
same basic set of data types as your suggested YAML subset; see the
following:

http://developer.apple.com/documenta...sts/index.html

Apple's property lists are stored as XML, but this isn't apparent to users.

--amk

A.M. Kuchling wrote:
>...
>
> Non-programmers don't edit configuration files, though; they use a GUI that
> presents a nice interface, and never see whatever format the settings are
> stored in.

It is precisely to enable the construction of these interfaces (and
other introspective tools) that it is better that these configuration
files not be Turing complete. What does the interface do when the
setting of a particular property depends on some complicated code? What
does it show the user about what the property means. Compare the
difficulty of building an app that reads and displays INI files to one
that introspects Python code!

Paul Prescod