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

[Gary Poster]

On Apr 27, 2009, at 4:33 PM, Wichert Akkerman wrote:

> Hi Gary,

Hey Wichert.  Sorry for not replying sooner.  I had already gone  
pretty far down the z3c.recipe.filetemplate road, so I kept going over  
there.  I just made a release.  It is http://pypi.python.org/pypi/z3c.recipe.filetemplate 
  if you are interested.  I obviously learned a lot from your design.   
I wanted to get that release out before replying.

>
> Previously Gary Poster wrote:
>> 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.
>
> Commit access to the collective is very liberal and generally arranged
> within 24 hours. Uli has both commit and pypi access for the package  
> and
> has already done a lot of work on it. Your contributions are very
> welcome as well!

Thank you, excellent.  If you want me to help migrating some of the  
z3c.recipe.filetemplate features over to the collective version, let  
me know.  I'd like to cooperate.  It would be strictly hobby-time  
work, though, and I have a marked reduction in that lately. :-/   
Hopefully things will have calmed down by the fall. :-)

>
>> 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.)
>
> The BSD license has very little restrictions. It certainly does not
> require licens statementsin every source file or so. Personally I find
> those to be clutter. If there is a missing license file that should be
> fixed.

I don't think the license is actually included in the collective  
recipe ATM.  Maybe I misremember.  But beyond that, BSD doesn't need  
headers, IIUC, so at least that's not necessary, yeah.

>
>> - 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 can see that being useful.

Cool.

>
>> - 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
>
> +1

Cool.  I like being able to specify a template source too though.   
Having to do that *and* specify the individual files seems like an  
unnecessary DRY violation.  I like Philipp's approach of enforcing a  
*.in -> * pattern, because it is a simple, useful, old convention.

>
>>
>> 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!
>> ``.
>
> This feels more like a feature for buildout: I can see this being  
> useful
> for other recipes as well.

It is a standard buildout recipe pattern, but it is usually  
implemented per recipe.  It's trivial to implement.  I did so.  I'm  
not sure how buildout would support it external to the recipe.

>
>> - 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.
>
> Again, this sounds more like a buildout extension. I've missed the
> option to do shell escapes in buildout as well.

Well, see how I did it, anyway, and see if you like the idea.  What  
you provide in the locals/globals is a decision that usually you want  
per-recipe, so again, I'm not sure how buildout would do it.

Thanks

Gary