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.
_______________________________________________
Product-Developers mailing list
Product-Developers@lists.plone.org
https://lists.plone.org/mailman/listinfo/product-developers