Christian Boos wrote: > And beyond that, we have some non-essential components that could be > moved from trac.* to tracext.*. > In particular, with 0.12 and multirepos, there's no need we continue to > give a special status to the svn backend. We could move the svn related > support below tracext.svn, giving it parallel status as the other > backends. Unfortunately, the Mercurial plugin still needs to be > distributed separately, due to licensing reasons. In the future, we > could bundle the Git plugin for example, provided one of the core Trac > developer "adopts" such a beast ;-)
I have semi-officially taken over maintenance for the GitPlugin. I have spoken to hvr and he's happy for me to do so as he's not using it much anymore. Unfortunately, I haven't had as much time as I'd like to apply many of the patches that are outstanding (such as 2.4 compatibility). Fortunately, I should be able to dedicate more time on it in about a month. >> I would like to move these plugins into a new top-level namespace >> "tracext", similar to the "hgext" namespace used in Mercurial. Plugins >> in tracext would be visible (that is, recorded in setup.py) but disabled >> by default. They can therefore be enabled with a single entry in the >> [components] section or through the "plugins" admin panel. >> >> Obviously, I wouldn't want to move all plugins from sample-plugins into >> tracext. I propose that the following criteria should be fulfilled for a >> tracext candidate: I'm fine with using the tracext.* namespace for additional plugins, however, I agree with Noah that we should make them real egg based plugins rather than single file plugins. Part of my reason for this is that I have an irrational hatred for single file plugins. Don't ask for the reasons, cus they aren't really good. Suffice to say, I don't like them and I think they should be used as little as possible Second, single file plugins can't use some of the nice features such as install_requires (which you note could be useful for the plugins that require ConfigObj). Third, I'd actually like to see the plugins not installed by default. I think it preferable that we make them full-fledged plugins, leave them in the source package, and then submit them separately to the cheeseshop. Installing them would then require a) tracext.* = enabled or trac.foo = enabled b) easy_install foo or building from source I think this is better because: a) easy_install is fairly easy b) keeps what we install smaller c) if one actually enables the full tracext.* namespace, then they don't inadvertently enable plugins that they didn't want but didn't know were installed. d) allows us to more easily rev the additional plugins, as their releases need not be tied directly to a trac release (though they could be) > Sure, and the quality and maintainability criterions are key points > here. Nevertheless I think this could eventually help to improve the > interaction between plugin developers and the Trac team. Plugin authors > developing "generally useful but optional functionality" could strive to > get their plugin included into tracext, and in order to meet the quality > criterions mentioned above, the end result could be only an increase in > the quality of the plugin, and a simpler way for the user to access the > extended feature, so a win on all accounts. This brings up the question of "enforcement". In addition to the plugins already on trac-hacks.org that Tim mentioned, the ActiveDirectoryAuthPlugin also uses the tracext.* namespace. So, what are the rules/requirements/etc for using tracext.*? As we don't have any real way of enforcing which plugins use the namespace, I think this is another reason why the plugins shouldn't be installed automatically. -John --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "Trac Development" group. To post to this group, send email to [email protected] To unsubscribe from this group, send email to [email protected] For more options, visit this group at http://groups.google.com/group/trac-dev?hl=en -~----------~----~----~----~------~----~------~--~---
