> -----Original Message----- > From: [email protected] [mailto:[email protected]] On > Behalf Of Remy Blank > Sent: Wednesday, October 14, 2009 2:51 PM > To: [email protected] > Subject: [Trac-dev] New top-level namespace "tracext" > > 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?
This has been talked about in the past, and in general I think it is a bad idea. If you want to make them into proper egg'd plugins, then do that. The single-file plugin system was designed to make things easier, not more complex. I think the bigger problem is that sample-plguins has gone from "example stuff" to "really useful stuff" and should either be made into Real plugins or moved into core. --Noah --~--~---------~--~----~------------~-------~--~----~ 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 -~----------~----~----~----~------~----~------~--~---
