[Grok-dev] Re: Salt & z3c.autoinclude

Martijn Faassen faassen at startifact.com
Fri Mar 21 19:36:11 EDT 2008

Ethan Jucovy wrote:
> 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.



More information about the Grok-dev mailing list