[Grok-dev] Re: the projects in progress
optilude at gmx.net
Tue Feb 26 03:30:38 EST 2008
Ethan Jucovy wrote:
> On Mon, Feb 25, 2008 at 9:22 AM, Martijn Faassen <faassen at startifact.com
> <mailto: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.
No toes. I just want this functionality to work. I'd have a chat with
Wichert, though. Oh, and the name ZCMLLoader is ugly. ;-)
> 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.
I can see the need for this, but the primary aim of Salt would be to
support the end user who wants to install an add-on product and have it
"just work" without having to mangle configuration files. Some kind of
override may be useful indeed, but if a config file is required we're no
closer than we are now, when you have to add the egg and then also add a
line to the buildout.cfg file to install a ZCML slug.
Author of `Professional Plone Development`, a book for developers who
want to work with Plone. See http://martinaspeli.net/plone-book
More information about the Grok-dev