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@lists.plone.org
https://lists.plone.org/mailman/listinfo/product-developers
--
Alex Clark · http://aclark.net/help-me-help-plone
_______________________________________________
Product-Developers mailing list
Product-Developers@lists.plone.org
https://lists.plone.org/mailman/listinfo/product-developers
