[Grok-dev] Re: Salt & z3c.autoinclude
Martijn Faassen
faassen at startifact.com
Fri Mar 21 19:36:11 EDT 2008
Ethan Jucovy wrote:
[snip]
> This concerns me, because I've already broken this assumption in my own
> code while using my previous incarnation of salt. I've actually found
> it useful to be able to create a plugin package which *doesn't*
> technically require the base platform, by putting the entire integration
> layer (declared interface implementations, utility hookups) in ZCML.
Wouldn't it still point to the base platform in some way? How do you
implement an interface, say, without importing it first? I guess you
could consider the ZCML of the package not to be really "in" the
package, though that's the opposite of the approach z3c.autoinclude takes.
> On the other hand, I just did a quick hand test, and it appears that the
> entry points aren't actually evaluated when the egg is installed. So
> it's only when you load() an entry point that the object it refers to
> must be __import__able.
> The entry point is only load()ed during
> execution of the <includePlugins> directive for that platform. So I
> think it's reasonable to assume/enforce that the "target" package is
> present in the environment at the time that the plugins are loaded.
Cool. :)
> All that said, I do still have a lingering hesitation about this format;
> it just seems to be a bit of an abuse of entry points and a deviation
> from their standard use. It will work though (thanks for noticing the
> dist attribute) so I'm willing to go along with it.
I understand the hestitation and I share it. But it's fairly pretty..
And I guess strictly speaking an entry point doesn't *have* to point to
code in its *own* package. :)
It looks like we're trying to do something with setuptools that isn't
quite supported by it. An entry point can be used by an egg to register
code that's run by a core. We already have a way to register code to be
run by a core that's way more powerful: the component architecture. We
only want to let a package register its existence with the core so that
it can choose to load it. We're slightly misusing entry points to look
up its existence as a plugin.
Regards,
Martijn
More information about the Grok-dev
mailing list