[buildout] develop vs extends/default.cfg
Hi All, What is the expected behaviour when the following are all true: - default.cfg has a develop key - buildout.cfg has a develop key, and extends a base.bfg - base.cfg has a develop key My hope is that all 3 should be set unioned for the develop options. However, my experience so far is that, at the least, the one in default.cfg is ignored... Chris
On Tue, Jun 1, 2010 at 9:22 AM, Chris Withers <chris@simplistix.co.uk> wrote:
Hi All,
What is the expected behaviour when the following are all true:
- default.cfg has a develop key - buildout.cfg has a develop key, and extends a base.bfg - base.cfg has a develop key
My hope is that all 3 should be set unioned for the develop options.
However, my experience so far is that, at the least, the one in default.cfg is ignored...
When a file extends another, it's options *override* options in the extended file unless you use += in the extending file, as in: develop += foo In which case, the new option values are appended to the ones from the extended file. Jim -- Jim Fulton
Jim Fulton wrote:
On Tue, Jun 1, 2010 at 9:22 AM, Chris Withers <chris@simplistix.co.uk> wrote:
Hi All,
What is the expected behaviour when the following are all true:
- default.cfg has a develop key - buildout.cfg has a develop key, and extends a base.bfg - base.cfg has a develop key
My hope is that all 3 should be set unioned for the develop options.
However, my experience so far is that, at the least, the one in default.cfg is ignored...
When a file extends another, it's options *override* options in the
...except extends, which does appear to overlay, right?
extended file unless you use += in the extending file, as in:
develop += foo
Hmm, okay, I think there's a bug lurking, please see attached .tgz When I run the buildout in package1, only package1's folde ends up being develop'ed. The key appears to be the += for the develop key in base.bfg. If I change that to just =, the behaviour seems as expected. However, The += was very deliberate, so as to allow develop paths to be specified user-wide in default.cfg, based on your advice above. Interestingly, any paths in default.cfg's develop *do* end up being used in the attached example. Where/how should I report this? cheers, Chris -- Simplistix - Content Management, Batch Processing & Python Consulting - http://www.simplistix.co.uk
Hi Jim, Did you get a chance to validate the issue I reported here? In any case, where should I put it so it doesn't get lost? cheers, Chris Chris Withers wrote:
Jim Fulton wrote:
On Tue, Jun 1, 2010 at 9:22 AM, Chris Withers <chris@simplistix.co.uk> wrote:
Hi All,
What is the expected behaviour when the following are all true:
- default.cfg has a develop key - buildout.cfg has a develop key, and extends a base.bfg - base.cfg has a develop key
My hope is that all 3 should be set unioned for the develop options.
However, my experience so far is that, at the least, the one in default.cfg is ignored...
When a file extends another, it's options *override* options in the
...except extends, which does appear to overlay, right?
extended file unless you use += in the extending file, as in:
develop += foo
Hmm, okay, I think there's a bug lurking, please see attached .tgz When I run the buildout in package1, only package1's folde ends up being develop'ed.
The key appears to be the += for the develop key in base.bfg. If I change that to just =, the behaviour seems as expected. However, The += was very deliberate, so as to allow develop paths to be specified user-wide in default.cfg, based on your advice above.
Interestingly, any paths in default.cfg's develop *do* end up being used in the attached example.
Where/how should I report this?
cheers,
Chris
------------------------------------------------------------------------
_______________________________________________ Distutils-SIG maillist - Distutils-SIG@python.org http://mail.python.org/mailman/listinfo/distutils-sig
-- Simplistix - Content Management, Batch Processing & Python Consulting - http://www.simplistix.co.uk
On Tue, Jun 29, 2010 at 12:01 PM, Chris Withers <chris@simplistix.co.uk> wrote:
Hi Jim,
Did you get a chance to validate the issue I reported here?
Not yet.
In any case, where should I put it so it doesn't get lost?
https://bugs.launchpad.net/zc.buildout/+bugs Jim -- Jim Fulton
participants (2)
-
Chris Withers -
Jim Fulton