[Grok-dev] Re: the projects in progress

[Ethan Jucovy]

On Mon, Feb 25, 2008 at 9:22 AM, Martijn Faassen <faassen at startifact.com>
wrote:

> Would OpenPlans be willing to work on moving this functionality into
> z3c.autoinclude? I think the test infrastructure we have for it should
> help solidify your functionality too, right?


Definitely -- it's got essentially the same dependencies and wants the same
(painful) test infrastructure, so it would certainly be beneficial.  I'm
hoping to push some incarnation of ZCMLLoader to our live deployments soon
so I'd be happy to work on this straightaway (assuming I can get my commit
access).  I wouldn't want to step on anyone's (martin/wiggy/hannosch/?) toes
here, though.

The only way I see is to have a way to here should be a way to turn
> *off* inclusion of a particular plugin. I think the ZCML exclude
> directive (which is available in an extension) could be used for this.
> This use case bears some thinking about as it's a problem we don't have
> for autoinclusion of dependencies. With plugins, the setup.py of the
> plugin is stating it wants to be included after all, and just the act of
> listing the package will make its ZCML be loaded by default.
>

I've been thinking about this a bit, partly because I frankly feel like
there's a bit too much magic if a package is included simply by virtue of
being installed, and partly because in development environments (where I
toggle plugins on and off frequently) having to disable an installed package
and later reinstall it ends up being quite a lot more hassle than dealing
with package-includes slug files.

A possibility I've considered (and implemented a first pass of, which works
well enough for my immediate purposes) is having a separate inifile specify
the active plugins as an alternative to packages pushing themselves for
inclusion.  In effect this transfers control of the plugin inclusion back to
the "core" package (or, as I prefer to think of it, to the particular
installation of the entire platform, core and plugins) but without the
implication that the plugin is a dependency.  On the one hand, I like this
because it satisfies my needs.  On the other hand, I'm not sure if it
defeats the purpose of broadcasting plugins altogether...

Incidentally, I've glanced very cursorily at the way Trac deals with plugins
and it seems to be somewhat similar to this approach.  Take this with a
grain of salt (ha!) and I'm sure someone can correct me, but it looks to me
like a plugin egg broadcasts its existence with an entrypoint, and the Trac
system itself is responsible for actually toggling those packages' inclusion
via a configuration file.  The TTW admin interface displays the available
plugins for convenient toggling; I'm not sure if the entrypoint is actually
useful for anything other than this display.

egj
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mail.zope.org/pipermail/grok-dev/attachments/20080225/3258822d/attachment.htm