On Mon, Feb 25, 2008 at 9:22 AM, 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;">
Would OpenPlans be willing to work on moving this functionality into<br>
z3c.autoinclude? I think the test infrastructure we have for it should<br>
help solidify your functionality too, right?</blockquote><div><br>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.<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;">The only way I see is to have a way to here should be a way to turn<br>
*off* inclusion of a particular plugin. I think the ZCML exclude<br>
directive (which is available in an extension) could be used for this.<br>
This use case bears some thinking about as it's a problem we don't have<br>
for autoinclusion of dependencies. With plugins, the setup.py of the<br>
plugin is stating it wants to be included after all, and just the act of<br>
listing the package will make its ZCML be loaded by default.<br>
<div class="Ih2E3d"></div></blockquote><div><br>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.<br>
<br>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...<br>
<br>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. <br>
<br>egj</div></div>