On Mon, Apr 19, 2010 at 10:28:37AM -0400, Jim Fulton wrote:
> On Mon, Apr 19, 2010 at 10:00 AM, Florian Friesdorf <f...@chaoflow.net> wrote:
> > Hi Jim, hi Christian,
> >
> > any further thoughts on this?
> 
> Not at this time. This is on my to-do list to look at.
> 
> I think your use case would be better handled through
> normal command-line option specification, as in:
> 
>   buildout -c deploy.cfg buildout:extends+=site1.cfg
> 
> but that doesn't work.  I think that should work and want
> to look at why it doesn't.

That'd be nice and would be sufficient for my current use case. And the
discussion about environment variables we could continue on the base of
this being functional.

I took a look at it and so far came up with two docstrings (attached).

I think I could simplify _open and make extends work as expected, in
case you are comfortable with delegating that (see also 'desired
behaviour' in the docstring for _open (attached).


florian

-- 
Florian Friesdorf <f...@chaoflow.net>
  GPG FPR: EA5C F2B4 FBBB BA65 3DCD  E8ED 82A1 6522 4A1F 4367
Jabber/XMPP: f...@chaoflow.net
  OTR FPR: 9E191746 213321FE C896B37D 24B118C0 31785700
IRC: chaoflow on freenode,ircnet,blafasel,OFTC
>From 186e8d9452c228ec68a229efde629b11d8add1db Mon Sep 17 00:00:00 2001
From: Florian Friesdorf <f...@chaoflow.net>
Date: Mon, 19 Apr 2010 19:14:04 +0200
Subject: [PATCH 1/2] docstring for _update_section

---
 src/zc/buildout/buildout.py |   21 +++++++++++++++++++++
 1 files changed, 21 insertions(+), 0 deletions(-)

diff --git a/src/zc/buildout/buildout.py b/src/zc/buildout/buildout.py
index 7d5ed47..c13fbfe 100644
--- a/src/zc/buildout/buildout.py
+++ b/src/zc/buildout/buildout.py
@@ -1373,6 +1373,27 @@ def _dists_sig(dists):
     return result
 
 def _update_section(s1, s2):
+    """update s1 by instructions from s2
+
+    '+' and '-' operators are understood, without an operator, s2 overwrites
+    s1.
+
+    A section in a config file (somefile.cfg) as base for s2:
+    [somesection]
+    key1 = value1
+    key2 += value2
+    key3 -= value3
+
+    Will arrive in the dictionary s2, like:
+    {
+        'key1': ('value1', 'somefile.cfg'),
+        'key2 +': ('value2', 'somefile.cfg'),
+        'key3 -': ('value3', 'somefile.cfg'),
+    }
+
+    The ' +'/' -' will be stripped of the key and the value in s1 altered
+    accordingly.
+    """
     s2 = s2.copy() # avoid mutating the second argument, which is unexpected
     for k, v in s2.items():
         v2, note2 = v
-- 
1.6.6.2

>From aabd5ddda35bdcf557d49b7615ad1bd8ad2daf90 Mon Sep 17 00:00:00 2001
From: Florian Friesdorf <f...@chaoflow.net>
Date: Mon, 19 Apr 2010 19:27:12 +0200
Subject: [PATCH 2/2] docstring for _open incl. temporary comments from analysis

---
 src/zc/buildout/buildout.py |   43 +++++++++++++++++++++++++++++++++++++++++++
 1 files changed, 43 insertions(+), 0 deletions(-)

diff --git a/src/zc/buildout/buildout.py b/src/zc/buildout/buildout.py
index c13fbfe..6222f37 100644
--- a/src/zc/buildout/buildout.py
+++ b/src/zc/buildout/buildout.py
@@ -1272,6 +1272,49 @@ def _open(base, filename, seen, dl_options, override):
     """Open a configuration file and return the result as a dictionary,
 
     Recursively open other files based on buildout options found.
+
+
+    Notes from analyzing the code here and in Buildout.__init__:
+
+    override is use to update dl_options and passed on to recursive calls of
+    _open
+
+    dl_options is updated with values from override and passed on to recursive
+    calls of _open.
+
+    extends-cache defined in either dl_options or override is used as
+    extends_cache
+
+    _open is used in Buildout.__init__, where it always receives a copy of
+    data['buildout'] as dl_options, i.e. the implicit feature of updating
+    dl_options is not used.
+
+    _open is used by itself recursively, where it always uses the very same
+    dl_options. However, it also passes on override and updates dl_options each
+    time with override.
+
+    The only two keys that justifiy the dl_options and override parameters are
+    extends-cache and extends, and currently they are only used for
+    extends-cache.
+
+
+    current behaviour:
+    - extends-cache can be defined anywhere and is overruled in the expected
+      order: user_defaults, configuration file, command line
+    - extends currently is only processed if defined in the configuration file
+      we are opening, not if it is passed via dl_options or override, i.e it is
+      not used if defined in user_defaults or on the command line.
+
+
+    desired behaviour:
+    - extends should be possible on the command line modifying a definition in
+      the configuration file
+    - extends should be possible in user_defaults, resulting in user_defaults
+      being derived from processing its extends and then being discarded
+      (optional)
+    - _open should not work on any arguments, but only return data it extracted
+      from the file it is supposed to open, following extends from the
+      configuration file or once using an extends passed in as override
     """
     _update_section(dl_options, override)
     _dl_options = _unannotate_section(dl_options.copy())
-- 
1.6.6.2

_______________________________________________
Zope-Dev maillist  -  Zope-Dev@zope.org
https://mail.zope.org/mailman/listinfo/zope-dev
**  No cross posts or HTML encoding!  **
(Related lists - 
 https://mail.zope.org/mailman/listinfo/zope-announce
 https://mail.zope.org/mailman/listinfo/zope )

Reply via email to