Ethan Jucovy
2010-11-21 14:40:36 UTC
A little while ago Paul checked in some changes to the zcml-autoinclusion
stuff. His checkins explain what's going on, but I wanted to mention it on
the list too where it'll be easier to find later on.
Paul found that distribute and setuptools don't iterate over entrypoints in
the same order. The result was that if you install opencore with
distribute, things break. Some plugins (opencore.cabochon I think) were
trying to use the IProvideSiteConfig utility during their own component
initialization. But the IProvideSiteConfig utility is itself registered by
a plugin (fassembler.configparser) -- so there was an implicit ordering
dependency, that fassembler.configparser's ZCML had to be loaded before
opencore.cabochon's.
The order in which plugins are loaded within a single <topp:includePlugins>
directive is based on the order of items yielded from iter_entry_points.
With setuptools, fassembler.configparser's [topp.zcmlloader] entrypoint
happened to appear first, but with distribute, it happened not to. So there
was a ComponentLookupError on startup if distribute was used.
The fix was to add a second plugin-point for ZCML:
<topp:includePlugins target="opencore_siteconfig" />
<topp:includePlugins target="opencore" />
So, fassembler.configparser now registers itself as a plugin for
"opencore_siteconfig", instead of "opencore", and it will always be loaded
before other plugins.
Conceptually, this makes better sense: fassembler.configparser provides a
utility whose existence is required by opencore, so it's a different kind of
plugin than all the rest, which provide strictly optional extra features.
If we ever have any other things that fit this description, we should
register them for "opencore_siteconfig" as well.
When I get around to porting opencore to z3c.autoinclude, this shouldn't
change anything. The feature (defining arbitrary plugin-points) exists
there too.
The changesets here were 27774:27777. That included one small change needed
in ZCMLLoader itself, to make this feature work.
--
Archive: http://www.coactivate.org/projects/opencore/lists/opencore-dev/archive/2010/11/1290350458585
To unsubscribe send an email with subject "unsubscribe" to opencore-dev-***@public.gmane.org Please contact opencore-dev-manager-81qHHgoATdGNjXQcXLqYpGD2FQJk+8+***@public.gmane.org for questions.
stuff. His checkins explain what's going on, but I wanted to mention it on
the list too where it'll be easier to find later on.
Paul found that distribute and setuptools don't iterate over entrypoints in
the same order. The result was that if you install opencore with
distribute, things break. Some plugins (opencore.cabochon I think) were
trying to use the IProvideSiteConfig utility during their own component
initialization. But the IProvideSiteConfig utility is itself registered by
a plugin (fassembler.configparser) -- so there was an implicit ordering
dependency, that fassembler.configparser's ZCML had to be loaded before
opencore.cabochon's.
The order in which plugins are loaded within a single <topp:includePlugins>
directive is based on the order of items yielded from iter_entry_points.
With setuptools, fassembler.configparser's [topp.zcmlloader] entrypoint
happened to appear first, but with distribute, it happened not to. So there
was a ComponentLookupError on startup if distribute was used.
The fix was to add a second plugin-point for ZCML:
<topp:includePlugins target="opencore_siteconfig" />
<topp:includePlugins target="opencore" />
So, fassembler.configparser now registers itself as a plugin for
"opencore_siteconfig", instead of "opencore", and it will always be loaded
before other plugins.
Conceptually, this makes better sense: fassembler.configparser provides a
utility whose existence is required by opencore, so it's a different kind of
plugin than all the rest, which provide strictly optional extra features.
If we ever have any other things that fit this description, we should
register them for "opencore_siteconfig" as well.
When I get around to porting opencore to z3c.autoinclude, this shouldn't
change anything. The feature (defining arbitrary plugin-points) exists
there too.
The changesets here were 27774:27777. That included one small change needed
in ZCMLLoader itself, to make this feature work.
--
Archive: http://www.coactivate.org/projects/opencore/lists/opencore-dev/archive/2010/11/1290350458585
To unsubscribe send an email with subject "unsubscribe" to opencore-dev-***@public.gmane.org Please contact opencore-dev-manager-81qHHgoATdGNjXQcXLqYpGD2FQJk+8+***@public.gmane.org for questions.