[Zope-dev] Re: Mixing recipes (zc.recipe.cmmi reuse)

[Sidnei da Silva]

On 9/24/07, Jim Fulton <jim at zope.com> wrote:
> > Or would it require the recipe
> > writer to explicitly 'subclass' (?) cmmi to get patch functionality?
>
> I prefer composition. A number of recipes reuse the egg recipe
> through composition.
>
> Generally, an egg will need to explicitly provide a Python API for
> other eggs. See, for example, http://pypi.python.org/pypi/
> zc.recipe.egg/1.0.0b6#egg-recipe-api-for-other-recipes

Gotcha, that makes sense.

> > Or even, would a 'post-fetch'/'pre-build' generalization be desired,
> > 'patch' being one such application?
>
> I have no idea what that is. :)

My intent is:

"Given any recipe, no matter where data is coming from (be it an egg
in PyPI, a Subversion checkout or a tarball), I would like to be able
to perform an operation in the 'local copy' of the data, without
depending on the person that wrote the recipe to have allowed me to do
so"

An example being, after a recipe that does a Subversion checkout runs,
my custom operation kicks in and applies a patch to the local copy
before the buildout processing continues.

I believe that this might be doable today by writing custom
configuration, but maybe it's such a common case that could be
simplified.

Maybe something along the lines of (note: this is all pseudo-config):

"""
[Step1]
recipe = some.recipe.checkout
url = svn://url-to-repo/package

[Step2]
recipe = zc.recipe.cmmi
source = {Step1:location}
patch = /path/to/my/patch

[zope2]
products = {Step2:location}
"""

I believe that something like this might already work today, if not it
might be easy to make it work that way. But what I'm after is to avoid
Step2 above by listing the patch to be applied in Step1 even if
'some.recipe.checkout' does not support the 'patch' option directly.

All in all, if you tell me that the hypotetical Step2 above really
can't be avoided and that the best option is to make
'some.recipe.checkout' and any other recipes out support the 'patch'
option directly, I would be fine with that too.

Does it make more sense now?

-- 
Sidnei da Silva
Enfold Systems                http://enfoldsystems.com
Fax +1 832 201 8856     Office +1 713 942 2377 Ext 214