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
[email protected]
https://lists.plone.org/mailman/listinfo/product-developers
--
Alex Clark · http://aclark.net/training
_______________________________________________
Product-Developers mailing list
[email protected]
https://lists.plone.org/mailman/listinfo/product-developers
