Christian Boos wrote: > John Hampton wrote: > Well, making them systematically .egg based somehow defeats the > "simplicity" part of the whole approach.
Making them .egg based isn't much harder. I'm also only talking about those plugins that would be getting the special status. > Note btw that I'd like to see our "external" plugins placed below a new > toplevel /plugins folder, with 0.1X subfolders That will be clearer than > using the /sandbox. I agree with this. >> Third, I'd actually like to see the plugins not installed by default. I >> think it preferable that we make them full-fledged plugins, leave them >> in the source package, and then submit them separately to the >> cheeseshop. > > That's not what I call simple, and that wouldn't be very different from > the current situation. Perhaps the difference between easy_install GitPlugin and easy_install http://trac-hacks.org/svn/gitplugin/0.11 doesn't seem like much on paper. However, it's a significant difference. The latter is scary, the former is understandable and easy. > Again, the idea is to have a set of high-quality optional components, > bundled and maintained with Trac (same releases, ready to use, to be > enabled within the web admin). Obviously not adequate for everything, > nor something every plugin author would like to be constrained to. And > not a call to include anything in Trac either. Let me cite the original > mail of Remy once again: > > 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. 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 > When it works... (you and the plugin provider need to be online; Well, one needs to be online to easy_install trac or download the source. The plugins would still be included in the source and therefore available if for some reason your trac install didn't have internet access. > for > example, try to easy_install the TracWikiTemplates plugin - ok right now > it works, but it's been installed despite being not even 0.11 compatible > - plugin hell). This is more the fault of the plugin developer rather than the tool. If the plugin developer doesn't specify what versions it should work with, then no tool will be able to figure out whether or not it should be installed. > I doubt this could be a real issue. The whole Trac egg directory is 8 or > 9Mb on my system (9 when all the .mo files are built). What if that > doubles? Hardly a big deal. As I said in my other email, I think this is a lame reason. Sure, we're not going to run anyone's drive out of space. It's still not a good reason for adding bloat. Especially stuff that's of dubious value to a large portion of users. 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. > Yes... but while that's possible to do, it's not something we will > entice people to do (like we currently don't say, don't bother, just do > [components] * = enabled). The preferred way would be to use the web > admin, being guided through a thematic ordering of the components (e.g. > "Version Control Backends" -> "Subversion" -> "Base system" | "Advanced > Property Renderers"). 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! 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. >> d) allows us to more easily rev the additional plugins, as their >> releases need not be tied directly to a trac release (though they could be) > > That would be one of the deciding factors for the plugin author, if she > would rather like to maintain her plugin independantly (with no strings > attached) or would like to see it part of the Trac distribution. Um, specifically regarding the sample plugins and those already in the trac repository, we ARE the plugin authors. I fail to see how your response has anything to do with OUR ability to release plugins out-of-sync with Trac releases. As these plugins aren't core, and only add features, and can be installed separately from Trac, I can't imagine why we would want to only release updates to said plugins alongside Trac releases. > Actually what would be wrong if *all* Trac plugins would use the tracext > namespace package? > Is something going to break? Will name conflicts be more frequent? > Especially if we would have some kind of "official" tree that plugin > authors could use as a guideline, e.g. > tracext.versioncontrol.backend.svn.*, > tracext.versioncontrol.backend.hg.*, tracext.ticket.clone, etc. > > Whether a component comes from a plugin installed individually (using > tracext namespace or not) or from a single file plugin, or from a > bundled module within the tracext package, I think it shouldn't make a > difference and all of them should be disabled by default and > discoverable in some nicely categorized and user friendly tree in the > web admin. I'm not actually against this. However, again, it depends on something that we don't have and won't have for a while. The closest that we'll come anytime soon, is having a well defined hierarchy for the tracext.* namespace. If we come up with that, I don't think it bad to encourage plugin developers to use the tracext.* namespace. -John --~--~---------~--~----~------------~-------~--~----~ 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 -~----------~----~----~----~------~----~------~--~---
