[Zope-dev] zc.buildout template recipes: concerns with [z3c|collective].recipe.template and other issues

[Gary Poster]

Thanks Uli, Wichert, and Hanno for working out the legal bits!  And  
thanks to Martijn and Martin for the other replies.

On Friday I had moved to z3c.recipe.filetemplate, for the reasons I  
had described then.  Philipp said I could run with that package.   
However, I'd prefer to work with a more active project.  If there's  
quick agreement on my additions to the collective recipe, and I'm  
given commit access, I'll switch.  I don't have time for a bikeshed  
discussion though, so if it descends much into that I'll stick with  
extending Philipp's recipe for now, and maybe switch over later when  
things settle down.

If I built on collective.recipe.template, I'd make the following  
changes.

REQUIRED

- verify that the BSD licensing rules are followed (headers, license  
inclusion, copyright statement, etc.), and fix if not.  I'd prefer if  
a foundation (e.g., the Plone Foundation) had the copyright.  (TBH,  
I'm more comfortable with the Zope Foundation repository because the  
rules for copyright assignment are clearer AIUI, even if they are  
breached sometimes, as was this case here.  But this isn't critical  
for my usage or contribution.)

- Add the ability to specify "eggs" and "extra-paths" the way you can  
for scripts.  These supply the values for three predefined options  
(available to the template).  If "paths" are the non-zip paths, and  
"all_paths" are all paths, then the options woud be defined roughly as  
given here:

     os-paths: (os.pathsep).join(paths)
     string-paths: ', '.join(repr(p) for p in all_paths)
     space-paths: ' '.join(paths)

- I have a directory of *.in files that will need to be processed,  
with shared options, and put in another directory.  Therefore, I'd  
like to be able to just specify the input directory and optionally the  
output directory. globs, for filters, might be a nice-to-have.  I came  
up with a spelling for all this that appealed to me for Philipp's  
package (which has a constraint of "I only use *.in inputs, and always  
strip ".in" for the output).  WIth my variant of his spelling, I could  
do everything I wanted with a line like

     files = *
     source-directory = templates

Then in ``templates`` you would arrange the directory structure you  
wanted, and make sure that your template files end with ".in".

I don't have a spelling I like as much for the "input" "output"  
pattern of the collective recipe.  I'd be OK with "input" and "output"  
being able to take multiple files:

     input = templates/etc/foo.in
                  templates/etc/bar.in
     output = etc/foo
                     etc/bar

That seems like it rocks the boat least for collective.recipe.template

NICE-TO-HAVE

Unless I discover I need this, these are just ideas that I might do on  
hobby time.

- Extend/override other buildout sections.  Here's an example, with  
Philipp's package.  Consider the following buildout::

     >>> write(sample_buildout, 'buildout.cfg',
     ... """
     ... [buildout]
     ... parts = message
     ...
     ... [template_defaults]
     ... mygreeting = Hi
     ... myaudience = World
     ...
     ... [message]
     ... recipe = z3c.recipe.filetemplate
     ... files = helloworld.txt
     ... extends = template_defaults
     ...
     ... myaudience = everybody
     ... """)

The "message" section now has values extended from the  
"template_defaults"
section, and overwritten locally.  A template of
``${mygreeting}, ${myaudience}!`` would thus result in ``Hi, everybody! 
``.

- Define option values in Python.  This would have the os and sys  
modules in the namespace, and would also have the buildout variables,  
and would have the paths and all_paths from the ``eggs`` section above  
so you could manipulate them as desired.

interpreted-options = path-separator=os.pathsep
                                       example-paths=' '.join('-t%s' %  
p for p in paths)

That would put ``path-separator`` and ``example-paths`` in the  
recipe's options.

- Make a script recipe that allows you to specify an  
``initialization_template``, as I described in my first email.

I'm pretty busy all around right now, and there's always the YAGNI  
concern, so I probably won't do those, but they seem like potentially  
good ideas.

Gary