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

[Ethan Jucovy]

On Fri, Mar 21, 2008 at 7:36 PM, Martijn Faassen <faassen at startifact.com>
wrote:

> 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.


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.)

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.

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.

[z3c.autoinclude.plugin]
target[base1.zcml] = base.package
target2[base2.zcml] = another.package

(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.)

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.


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.  :)

egj
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mail.zope.org/pipermail/grok-dev/attachments/20080321/3d367e4a/attachment.htm