Hello list, I'm fully supportive to Remy proposal, which I think goes into the right direction, as it echoes some older discussions for having a simpler way to install and configure Trac out of the box, with a "minimal" setup that could then be expanded through an improved plugins panel in the web admin.
See e.g. http://groups.google.com/group/trac-dev/msg/97a217b2b21c52bf and the follow-up from David Abrahams. We also need to imagine a better way to "organize" the modules, instead of the 2 level list of packages/components we have now. Remy Blank wrote: > We currently have a small number of directly useful plugins in the > sample-plugins folder, next to a larger number of sample plugins that > only demonstrate some aspect of Trac programming. > 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 ;-) > More specifically, the authz_policy.py and extrapermissionprovider.py > plugins on trunk, and the commit_ticket_update.py plugin on multirepos, > provide generally useful functionality without requiring editing the > source code. > Note that the authz_policy.py introduces an extra dependency (ConfigObj), so we need some additional logic to handle such cases (same thing for svn support, of course). > Until now, users had to extract these plugins from the source package or > download it from the repository browser, and install them in their > plugins folder. This makes it difficult to find out the exact version > that was used when reporting an issue, as $Revision$ tags are not > expanded in the repo browser. Moreover, they had to be updated manually > when upgrading Trac core. > > 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: > > > - The plugin should provide some self-contained, generally useful but > optional functionality. > I'm not sure "self-contained" is that pertinent. I can imagine some optional features that depend on some other optional features ... e.g. the svn property renderers depending on the svn backend. > - The plugin should not require editing the source code to be > configured for an install, but be usable as-is. > > - The plugin should be actively maintained and tested regularly, and > its code quality should equate that of the trac namespace. > > Note that the idea is *not* to gradually move plugins from Trac-Hacks > back into core, but to have a location where we can place optional core > functionality so that it is readily available and easy to enable. > 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. The recently discussed "filesystem" version control backend recently discussed on th-users list is also a good candidate for tracext ;-) (see https://lists.trac-hacks.org/pipermail/th-users/2009-October/000080.html). -- Christian --~--~---------~--~----~------------~-------~--~----~ 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 -~----------~----~----~----~------~----~------~--~---
