[Grok-dev] Re: the projects in progress

[Martin Aspeli]

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.

Martin

-- 
Author of `Professional Plone Development`, a book for developers who
want to work with Plone. See http://martinaspeli.net/plone-book