On Fri, Mar 21, 2008 at 7:36 PM, Martijn Faassen <<a href="mailto:faassen@startifact.com">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;">
Ethan Jucovy wrote:<br>
[snip]<br>
<div class="Ih2E3d">> This concerns me, because I've already broken this assumption in my own<br>
> code while using my previous incarnation of salt. I've actually found<br>
> it useful to be able to create a plugin package which *doesn't*<br>
> technically require the base platform, by putting the entire integration<br>
> layer (declared interface implementations, utility hookups) in ZCML.<br>
<br>
</div>Wouldn't it still point to the base platform in some way? How do you<br>
implement an interface, say, without importing it first? I guess you<br>
could consider the ZCML of the package not to be really "in" the<br>
package, though that's the opposite of the approach z3c.autoinclude takes.</blockquote><div><br>Well, the ZCML points to // implicitly imports the base platform: <class><implements interface="base.platform.interface"/></class> and so on. I avoided putting any references to the base platform (or, for that matter, to any zope libraries) in the python code of the plugin, though, so the code itself can be used (that is, imported and run, without loading its ZCML) by any package. (It's a configuration parsing utility which I want to make available to both a zope project and a pylons project.)<br>
<br>So for now it's really more that the package which contains this plugin either uses zope + the base platform, or neither. That's what I mean when I say it doesn't require the base platform -- all of the Python code contained in the package can be imported and run without any modules from the platform being present. The base package is almost more of an extra requirement; if the ZCML in the package is executed, at that point the platform becomes required. <br>
<br>If I end up having a second zope platform which wants to use it (which currently looks unlikely, and which I can't really imagine ever needing anyway) I would need to be able to register the package as a plugin for multiple platforms, each with a different starting point for its ZCML.<br>
<br>[z3c.autoinclude.plugin]<br>target[base1.zcml] = base.package<br>target2[base2.zcml] = another.package<br><br>(Neither of these extensions -- multiple base platforms or arbitrary zcml -- is currently implemented, and since I don't need either I don't have any reason to push for this; I'm just musing at this point.)<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;">It looks like we're trying to do something with setuptools that isn't<br>
quite supported by it. An entry point can be used by an egg to register<br>
code that's run by a core. We already have a way to register code to be<br>
run by a core that's way more powerful: the component architecture. We<br>
only want to let a package register its existence with the core so that<br>
it can choose to load it. We're slightly misusing entry points to look<br>
up its existence as a plugin.</blockquote><div><br>True. Even if we were to use the more conventional syntax and use the entry point to expose a Python object contained within the plugin package (or contained within a dependency of it) the abuse would still be much the same; the object being broadcast would not actually be containing any useful or necessary information. So I'm happy to call all the abuses equal and plow ahead with the prettiest one. :)<br>
<br>egj<br></div></div>