Noah Kantrowitz wrote: > This has been talked about in the past, and in general I think it > is a bad idea.
The few discussions I have found in the archives didn't seem to reach any conclusion. Do you have any pointers to concrete decisions about this? My feeling is that some people were in favor of such an inclusion mechanism, some were against, and in the end nothing was done because nobody cared to do the work. Could you please elaborate on why you think this is a bad idea? > If you want to make them into proper egg'd plugins, then do that. No, that's not what I want. The plugins I mention (except for the recently-added extrapermissionprovider.py) have been included with Trac for a long time, and have been used extensively. However, their usage has always been awkward due to being located in sample-plugins. I want to keep them in core, while simplifying their use. > The single-file plugin system was designed to make things easier, not > more complex. What do you feel is made more complex by moving them to a "tracext" namespace, where they can easily be enabled and are updated automatically with Trac? > 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. Not quite. Most of the plugins in sample-plugins actually are sample plugins that cannot be used as-is, and should remain there. What I am trying to do is extract the useful stuff and make it accessible. Moving them into the "trac" namespace is not a good idea, because they should not be enabled by default. Also, doing that would automatically make their config options visible on TracIni, which makes basic configuration more complex. -- Remy
signature.asc
Description: OpenPGP digital signature
