On Fri, Mar 21, 2008 at 11:47 AM, Martijn Faassen <<a href="mailto:faassen@startifact.com" target="_blank">faassen@startifact.com</a>> wrote:<br><div class="gmail_quote"><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
I don't see that you should have to spell out the dotted name of the<br>
plugin package though: I see entry points contain a 'dist' attribute.<br>
Couldn't you use this information?</blockquote><div><br>Ah, I never noticed that, but that looks good. So scratch what I said about containing no information about their provider. :) This should work fine.<br><br>
</div><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
The right hand side needing something importable seems like a more<br>
troublesome problem. Then again, a plugin to an application will almost<br>
certainly have a dependency on that package, so a plugin for Plone will<br>
depend on Plone and import things from it. This means we could do the<br>
following:<br>
<br>
[z3c.autoinclude.plugin]<br>
target = package.plugged.into<br>
<br>
For plone (if it's in 'plone.app'):<br>
<br>
[z3c.autoinclude.plugin]<br>
target = plone.app</blockquote><div><br>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.<br>
<br>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.<br>
<br>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.<br>
<br>egj<br></div></div>