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.
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. 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. - 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. Thoughts? -- Remy
signature.asc
Description: OpenPGP digital signature
