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

Alex Clark aclark at aclark.net
Fri Apr 15 02:17:18 UTC 2011


On 4/14/11 4:45 PM, Dylan Jay wrote:
> On 15/04/2011, at 3:09 AM, Alex Clark wrote:
>
>> Hi,
>>
>> 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.
>>
>> OK I took a stab at this here:
>>
>> -
>> http://dev.plone.org/collective/changeset/237189/collective.transmogrifier/branches/aclark-mr-migrator-compat
>>
>>
>> Which works OK with packages that declare entry points like the one here:
>>
>> -
>> http://dev.plone.org/collective/changeset/237623/transmogrify.filesystem/branches/aclark-mr-migrator-compat
>>
>>
>> This works because there is ZCML in that package and c.transmogrifier
>> calls zcml.load on it.
>
> It looks like you have two systems for registration which do the same
> thing. The autoinclude loads zcml and the special
> collective.transmogrifier entrypoint also loads zcml. Wasn't the idea of
> the special collective.transmogrifier entrypoint to bypass zcml
> alltogeather, ie be an alternate registration syntax by itself so zcml
> wasn't needed? ie somthing like
>
> for object in iter_entry_points(group='collective.transmogrifier',
> name=None):
> object.load()
>
> and object.load() is going to call a method the plugin author has
> provided to call register all they blueprints without zcml

OK that sounds reasonable. I'd consider this to be a first step in the 
right direction though.

>
> see
> http://wiki.pylonshq.com/display/pylonscookbook/Using+Entry+Points+to+Write+Plugins

Yup, I've read that like 5000 times :-) The example is fairly simple, 
and though it helped me get this far, it doesn't go beyond a few lines 
of code for each of the moving parts (i.e. plugin system and plugin 
consumer).




>>
>> But I wonder how I can make it work for blueprints like this one:
>>
>> -
>> http://dev.plone.org/collective/browser/collective.transmogrifier/trunk/src/collective/transmogrifier/sections/tests.py#L204
>>
>>
>> Where the code is loaded via provideUtility…
>>
>>
>> Do I need to make a "special exception" to handle this case?
>
> if that one was meant to be used outside of those internal tests then it
> would have been registered with zcml. So it's not meant to be used by
> others.


As MJ pointed out to me a package author can do:

<utility
  component="collective.transmogrifier.sections.tests.PrettyPrinter"

and off they go.

But the goal here is to make this sort of thing easily configurable with 
mr.migrator IMHO.


Alex



>
>
>>
>>
>> Thanks for any pointers,
>>
>>
>>
>> Alex
>>
>>
>>
>>
>>>
>>> Wichert.
>>>
>>
>>
>> --
>> Alex Clark · http://aclark.net/training
>>
>> _______________________________________________
>> Product-Developers mailing list
>> Product-Developers at lists.plone.org
>> https://lists.plone.org/mailman/listinfo/product-developers


-- 
Alex Clark · http://aclark.net/training




More information about the Product-Developers mailing list