[Product-Developers] Calling all collective.transmogrifier blueprint authors

[Alex Clark]

On 3/26/11 10:37 AM, Dylan Jay wrote:
> On 26/03/2011, at 6:44 AM, Alex Clark wrote:
>
>> On 3/25/11 11:45 AM, Wichert Akkerman wrote:
>>> On 2011-3-25 16:03, Alex Clark wrote:
>>>> - Ask for feedback on the issue of making collective.transmogrifier
>>>> listen for a "transmogrify" target, coming from blueprints who add an
>>>> entry point like:
>>>>
>>>> setup(
>>>> ...
>>>>
>>>> entry_points="""
>>>> [z3c.autoinclude.plugin]
>>>> target = transmogrify
>>>> """
>>>> )
>>>>
>>>>
>>>> That would allow a buildout[1] like this to work:
>>>>
>>>>
>>>>
>>>> [mr.migrator]
>>>> recipe = mr.migrator
>>>> pipeline = pipeline.cfg
>>>> eggs =
>>>> transmogrify.filesystem
>>>> transmogrify.ploneremote
>>>> transmogrify.pathsorter
>>>> transmogrify.printer
>>>>
>>>>
>>>> Otherwise, we'll need to make mr.migrator accept the ZCML parameter,
>>>> and
>>>> end users will have to list their blueprints twice:
>>>
>>> Why not use entrypoints instead instead of relying on zcml in between?
>>> That way you don't need to list them twice, and you get discovery
>>> directly from setuptools.
>>
>>
>> Why not indeed, that is one of the points of this thread… I have a
>> branch waiting to be merged down, pending MJ's approval:
>> http://svn.plone.org/svn/collective/collective.transmogrifier/branches/aclark-mr-migrator-compat/
>>
>>
>> But he expressed some concern about the overhead; so this is the part
>> where blueprint authors chime in and say "yes! that would be great!" ;-)
>
> I think what Wichert is suggesting to register configurations and
> blueprints directly with entry_points
>
> Something like this
>
> entry_points = {
> 'transmogrifier.config' :
> ['funnelweb = funnelweb.registerConfig'],
> 'transmogrifier.blueprint':
> ['transmogrify.xmlsource = transmogrify.xmlsource.xmlsource:XMLSource']
> }
>
> We could put some code into collective.transmogrifier which use these
> registrations directly as shown in
>
> http://reinout.vanrees.org/weblog/2010/01/06/zest-releaser-entry-points.html
>
>
> This would bypass the zcml. plugin authors then have a choice of which
> way they want to register, zcml or entry_point.
>
> except that if they register via zcml in which case mr.migrator would
> still need a zcml= option to support those plugins.


In that case I would say "huh?" :-) OK this thread is going a bit off 
the rails (for me at least), but let me see if I understand.

Option 1(which I suggested in the first email)
==============================================

- includePlugins package="transmogrify" in c.transmogrifier

- blueprints target "transmogrify"

- mr.migrator "Just works" (as would any other "runner" e.g. GS, browser 
view, etc.) because c.transmogrifier ensures all blueprints are 
available at runtime (via ZCML).

Option 2(what Wichert suggested)
================================

- Use entrypoints instead (of ZCML, in particular instead of a zcml= in 
mr.migrator)

entry_points = {
'transmogrifier.config' : ['funnelweb = funnelweb.registerConfig'],
'transmogrifier.blueprint': ['transmogrify.xmlsource = 
transmogrify.xmlsource.xmlsource:XMLSource']
}

(that doesn't look like valid syntax, but i guess the point is in 
mr.migrator you specify… nope. i got nothing, sorry :-))


XXX Can someone fill in the rest here?


FWIW, I'm not trying to give blueprint authors more options, I'm trying 
to give end users the ability to run c.transmogrifier-based migrations.

If c.transmogrifier is a "framework for building pipelines" and "a 
migration" is a specific set of blueprints in a specific pipeline, then 
"mr.migrator" is a way for end users to mix and match those 
blueprints/pipelines.

As it stands, AFAICT if I want to use a particular blueprint, I have to 
create a "migration package" and configure my migration inside the 
package (which I personally do not want to do).


Alex











>
>
>>
>>
>>
>> Alex
>>
>>
>>
>>
>>
>>
>>
>>>
>>> Wichert.
>>>
>>
>>
>> --
>> Alex Clark · http://aclark.net/help-me-help-plone
>>
>> _______________________________________________
>> Product-Developers mailing list
>> Product-Developers at lists.plone.org
>> https://lists.plone.org/mailman/listinfo/product-developers


-- 
Alex Clark · http://aclark.net/help-me-help-plone