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

Alex Clark aclark at aclark.net
Sat Mar 26 21:11:34 UTC 2011


On 3/26/11 1:29 PM, Dylan Jay wrote:
>
> On 27/03/2011, at 3:05 AM, Alex Clark wrote:
>
>> 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).
>
> ok skip the part about registering pipelines for now.
> people who share blue prints have to either
> a) register them in zcml and then also include the autoinclude entry_point
> or
> b) just register them with an entry_point syntax such as
> 'transmogrifier.blueprint': ['transmogrify.xmlsource =
> transmogrify.xmlsource.xmlsource:XMLSource']
>
> The advantage of b) is you no longer need zcml and there is no need for
> z3c.autoinclude.


OK I get it, I think.

While refreshing myself on entry points, I found: 
http://stackoverflow.com/questions/774824/explain-python-entry-points/774859#774859

which sounds like a pretty good description of what we might like 
c.transmogrifier to become, i.e. "allowing one package do use plugins 
that are in another package".


But I have no idea if this is something we can easily convince everyone 
is appropriate to live in c.transmogrifier… certainly includePlugins was 
not.






Alex










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




More information about the Product-Developers mailing list