Proposed change to buildout configuration-file handling
An annoyance in buildout configurations, resulting from it's use of ConfigParser, is that configuration data lines are stripped of leading spaces. This means configurations like this: [paste.ini] recipe = zc.recipe.deployment:configuration text = [app:main] use = egg:bobo bobo_resources = cmsapp filter-with = zodb [filter:zodb] use = egg:zc.zodbwsgi configuration = <zodb main> <zeoclient> server ${main-db-server:address} </zeoclient> </zodb> <zodb index> <zeoclient> server ${index-db-server:address} </zeoclient> </zodb> [server:main] use = egg:Paste#http host = localhost port = 8080 Don't work because leading whitespace is stripped, forcing me to use hacks like this:: [paste.ini] recipe = zc.recipe.deployment:configuration s = text = ${:s}[app:main] ${:s}use = egg:bobo ${:s}bobo_resources = cmsapp ${:s}filter-with = zodb ${:s} ${:s}[filter:zodb] ${:s}use = egg:zc.zodbwsgi ${:s}configuration = ${:s} <zodb main> ${:s} <zeoclient> ${:s} server ${main-db-server:address} ${:s} </zeoclient> ${:s} </zodb> ${:s} <zodb index> ${:s} <zeoclient> ${:s} server ${index-db-server:address} ${:s} </zeoclient> ${:s} </zodb> ${:s} ${:s}[server:main] ${:s}use = egg:Paste#http ${:s}host = localhost ${:s}port = 8080 :( I propose to give buildout it's own parser that begaves like ConfigParser, with the exeption that leading whitespace won't be stripped, but will be dedented with textwrap.dedent. There is some potential for breakage as some option values without leading whitespace before would get it now, but my sense is that this would be unlikely. Thoughts? If I did that (and I really want to do this) I'd release a beta to help people assess the impact. Jim -- Jim Fulton http://www.linkedin.com/in/jimfulton
On Sun, Mar 06, 2011 at 10:34:01AM -0500, Jim Fulton wrote:
An annoyance in buildout configurations, resulting from it's use of ConfigParser, is that configuration data lines are stripped of leading spaces. ... I propose to give buildout it's own parser that begaves like ConfigParser, with the exeption that leading whitespace won't be stripped, but will be dedented with textwrap.dedent.
There is some potential for breakage as some option values without leading whitespace before would get it now, but my sense is that this would be unlikely.
Thoughts? If I did that (and I really want to do this) I'd release a beta to help people assess the impact.
Woot! +2 I've had to do contortions like this initialization = # haaaaack because zc.recipe.testrunner 1.4.0 produces an _insane_ # bin/test that cannot be run with bin/coverage run bin/test, or even # bin/python bin/test import coverage, atexit c = coverage.coverage(data_file='../../../.coverage') def _when_done(c=c): c.stop(), c.save() atexit.register(_when_done) c.start() because of that, and because the ${:s} trick never occurred to me. There's also another -- perhaps minor -- reason to use a custom parser. That way you could use += more than once in a section, i.e. develop = foo develop += bar develop += baz as an alternative to develop = foo bar baz (I've wanted to do that so that I could comment out each develop line individually, to disable it) Marius Gedminas -- #define QUESTION ((bb) || !(bb)) /* Shakespeare */
On Sun, Mar 6, 2011 at 10:34 AM, Jim Fulton <jim@zope.com> wrote:
An annoyance in buildout configurations, resulting from it's use of ConfigParser, is that configuration data lines are stripped of leading spaces.
+1 How should we handle the dedenting? Would both of these assignments produce the same result? (I.e., no leading whitespace at all): foo = first line second line third line foo = first line second line third line -- Benji York
On Sun, Mar 6, 2011 at 2:46 PM, Benji York <benji@benjiyork.com> wrote:
On Sun, Mar 6, 2011 at 10:34 AM, Jim Fulton <jim@zope.com> wrote:
An annoyance in buildout configurations, resulting from it's use of ConfigParser, is that configuration data lines are stripped of leading spaces.
+1
How should we handle the dedenting?
Would both of these assignments produce the same result? (I.e., no leading whitespace at all):
foo = first line second line third line
foo = first line second line third line
I'm thinking no. The first example would have no leading whitespace, but the second would have leading whitespace on the send and third lines. I can maybe see treating values that begin on the option line differently, but fear that would make the mechanism too hard to explain. I'm interested in other folks opinions though. Jim -- Jim Fulton http://www.linkedin.com/in/jimfulton
Le 06/03/2011 16:34, Jim Fulton a écrit :
An annoyance in buildout configurations, resulting from [its] use of ConfigParser, is that configuration data lines are stripped of leading spaces.
configparser is much better in 3.2 (I’m cc’ing the author of those improvements and new module maintainer), and I already suggested a standalone release on PyPI for older Pythons. It would be nice to work out whether your needs could be addressed directly at the source before being forced to fork or monkey-patch. Regards
On Mon, Mar 7, 2011 at 5:23 AM, Éric Araujo <merwok@netwok.org> wrote:
Le 06/03/2011 16:34, Jim Fulton a écrit :
An annoyance in buildout configurations, resulting from [its] use of ConfigParser, is that configuration data lines are stripped of leading spaces.
configparser is much better in 3.2 (I’m cc’ing the author of those improvements and new module maintainer), and I already suggested a standalone release on PyPI for older Pythons. It would be nice to work out whether your needs could be addressed directly at the source before being forced to fork or monkey-patch.
3.2 is irrelevant. While I plan to port buildout to Python 3 at PyCon, I intent to maintain buildout on Python 2 for some time, so there's really no point in depending on changes made in 3.2. Jim -- Jim Fulton http://www.linkedin.com/in/jimfulton
Wiadomość napisana przez Jim Fulton w dniu 2011-03-07, o godz. 12:35:
On Mon, Mar 7, 2011 at 5:23 AM, Éric Araujo <merwok@netwok.org> wrote:
Le 06/03/2011 16:34, Jim Fulton a écrit :
An annoyance in buildout configurations, resulting from [its] use of ConfigParser, is that configuration data lines are stripped of leading spaces.
configparser is much better in 3.2 (I’m cc’ing the author of those improvements and new module maintainer), and I already suggested a standalone release on PyPI for older Pythons. It would be nice to work out whether your needs could be addressed directly at the source before being forced to fork or monkey-patch.
3.2 is irrelevant.
While I plan to port buildout to Python 3 at PyCon, I intent to maintain buildout on Python 2 for some time, so there's really no point in depending on changes made in 3.2.
If that changes anything, you can expect a 2.4+ compatible version soon (how soon depends on when you need it), much like unittest2 ports Python 3.2 unittest down. -- Pozdrawiam serdecznie, Łukasz Langa tel. +48 791 080 144 WWW http://lukasz.langa.pl/
On Mon, Mar 7, 2011 at 6:42 AM, Łukasz Langa <lukasz@langa.pl> wrote:
Wiadomość napisana przez Jim Fulton w dniu 2011-03-07, o godz. 12:35:
On Mon, Mar 7, 2011 at 5:23 AM, Éric Araujo <merwok@netwok.org> wrote:
Le 06/03/2011 16:34, Jim Fulton a écrit :
An annoyance in buildout configurations, resulting from [its] use of
ConfigParser, is that configuration data lines are stripped of leading
spaces.
configparser is much better in 3.2 (I'm cc'ing the author of those
improvements and new module maintainer), and I already suggested a
standalone release on PyPI for older Pythons. It would be nice to work
out whether your needs could be addressed directly at the source before
being forced to fork or monkey-patch.
3.2 is irrelevant.
While I plan to port buildout to Python 3 at PyCon, I intent to maintain buildout on Python 2 for some time, so there's really no point in depending on changes made in 3.2.
If that changes anything, you can expect a 2.4+ compatible version soon (how soon depends on when you need it), much like unittest2 ports Python 3.2 unittest down.
How so? As a pypi release? I'd consider it under those circumstances. I'll take a look at the new version before writing my own then (although writing my own is a pretty trivial exercise of copying the existing _read method and making a few minor tweaks). Jim -- Jim Fulton http://www.linkedin.com/in/jimfulton
2011/3/7 Łukasz Langa <lukasz@langa.pl>:
If that changes anything, you can expect a 2.4+ compatible version soon (how soon depends on when you need it), much like unittest2 ports Python 3.2 unittest down.
And for Python 2 at least, it can even take it's real name, configparser. That won't work for Python 3.1, though. -Fred -- Fred L. Drake, Jr. <fdrake at acm.org> "A storm broke loose in my mind." --Albert Einstein
participants (6)
-
Benji York -
Fred Drake -
Jim Fulton -
Marius Gedminas -
Éric Araujo -
Łukasz Langa