John Hampton wrote: > So I'm entirely confused as to the point of using tracext at all? why > not simply put them under trac.opt.* and be done with it? This means we > don't have to worry about conflicts or other issues. We can also simply > set them as disabled by default so that they can be enabled via the web > admin
Ah, yes, that's what I just wrote as well. A disabled "trac.opt" package makes more sense than a namespace. Maybe we should not be talking about plugins, but about features that are disabled by default. Like Christian said: a set of high-quality optional components, bundled and maintained with Trac (same releases, ready to use, to be enabled within the web admin). In this context, the whole eggs vs. single-file plugins issue is actually a red herring. The functionality is already packaged with Trac, let's just make it easier to enable. I also don't really see an advantage either in forcing or encouraging plugin authors to place their plugins in the tracext namespace. As long as we have our own private package for optional features, they can do as they like. > Every plugin that is found anywhere on the path, enabled or not, still > needs to be loaded by setuptools when trac starts. Trac already isn't a > speed demon. Anything to keep it from getting slower can only help. That's true, but only for the initial startup, which should be relatively infrequent. > I agree that this (the web admin hotness) would be great. However, > let's be realistic. At our current rate that's not going to happen > until Trac 0.17. My 1st grader will be graduating college by then! Hey, I'm working as fast as I can! ;-) Sure, a full plugin management interface with automatic download from the Cheeseshop and all isn't on the radar yet. Even the nice categories that Christian suggested are a bit far off. But... > Having an easy to use, capable web admin interface for managing plugins > makes this whole discussion moot. The fact is that we don't have that > now, nor are we going to have something decent in the near future. One thing I would like to do pretty soon (probably not for 0.12, though) is to present the components in the plugin admin panel in a tree by package, and to have a way to display the docstrings of packages and components. These could contain a description of the component or package and instructions about its configuration. -- Remy
signature.asc
Description: OpenPGP digital signature
