Hi there, Gary Poster wrote: > I'm concerned about the state of the zc.buildout template recipes. I > want one. I want some one-off files, specific to a certain project, > for which writing a standalone recipe feels very heavy. > > Here are the template recipes I found: > > collective.recipe.template (Wichert Akkerman) > iw.recipe.template (Ingeniweb) > inquant.recipe.textfile (Stefan Eletzhofer) > z3c.recipe.template (Uli Fouquet) > buildout_script (Nathan Yergler) > z3c.recipe.filetemplate (Philipp von Weitershausen) > > First, on the basis of this list, it strikes me that a lot of people > want this functionality. Putting template support into zc.buildout > itself would be nice. I envision some APIs (like the ones in > easy_install.py that zc.recipe.egg uses) that other recipes could use > easily. I would even want recipes like the zc.recipe.egg script > recipe to allow specifying initialization code by identifying a > template (i.e., ``initialization_template = buildout_templates/foo``, > which would parse the given template and insert the code the same way > the ``initialization`` parameter works).
I was thinking about something like this for z3c.recipe.template as well. Should be not too difficult. But, well, first the legal stuff ;) > Second, there's no clear winner at the moment. I happened to find > z3c.recipe.template, buildout_script, and z3c.recipe.filetemplate > first. On the basis of those three, and the comments that > z3c.recipe.template made about collective.recipe.template, > iw.recipe.template, and inquant.recipe.textfile, I decided to settle > on z3c.recipe.template to be the package to which I would contribute. > It has tests, a variable substitution approach that seems to work well > with buildout, and recent development activity. Glad you liked it :) > However, on starting to hack on its documentation to sketch the > changes I wanted, I gradually realized that this was a fork of > collective.recipe.template. Since collective.recipe.template is > listed as BSD in setup.py (though I saw no explicit licensing > otherwise), placing z3c.recipe.template in the zope.org ZPL-only > repository is problematic. Yes, you're certainly right. Thanks for spotting this! The history: although I started the project from scratch, I also copied some central parts from Wicherts (very clean and straight) recipe. I'd therefore consider it myself to be derivative work (or fork) of BSD licensed code. In the beginning my code should go into collective.recipe.template itself (Wichert agreed), but I wasn't granted committer access to the collective repository yet. Of course I requested to be approval and waited for weeks, but nothing happened. As we needed the extra-functionality in grokproject urgently and Wichert had no time to implement it himself, I created a new project based on Wicherts work. > Since I don't find the prospect of creating yet another template > recipe attractive, and Philipp's z3c.recipe.filetemplate looks like it > can take my new features while maintaining backwards compatibility, > I'll try that next, I suppose. > > But meanwhile, I'm concerned about the state of z3c.recipe.template. > IMO, Uli and Wichert should try to reconcile the licensing and forking > issues (with Uli taking the lead in those discussions, ideally, since > he is the one who forked). z3c.recipe.template should be removed from > the zope.org repository, unless/until the licensing story is cleaned up. I removed the source from the repository and asked Wichert for how to proceed. If there's a lawyer in the house: how can one switch from BSD to ZPL for derivative works if both parties agree? I put the sources in a private repository meanwhile. I'd prefer to put the sources into Zope repository again, but if this is legally too difficult, they will stay hosted elsewhere. > And maybe we can start to settle on a common template approach soon. > This should be a problem that is solved for buildout canonically, > IMO. I'll be happy to try and see if my features are generally > interesting, once I make them. What features do you think of? I already had some requests for features that were too 'special' so I refused to implement them. What I like with Wichert's approach (and which I tried to perpetuate) is, that it does simple things in a clear way and does not promise to do more. This way it does not become overloaded/overengineered. I'd propose to keep it this way. The initialization-code feature you mention above, however, sounds like an attractive extension (to whatever recipe or buildout itself). Best regards, -- Uli
Description: Dies ist ein digital signierter Nachrichtenteil
_______________________________________________ Zope-Dev maillist - Zope-Dev@zope.org http://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope )