Jan Schukat wrote: > The format of the plugins that should become part of the official > release, for easy but optional activation is secondary I guess. Use > what fits the requirements best.
The differences between single file plugins and full plugins are: a) single file plugins can't be easy_install'ed b) due to a) there is no reason to put single file plugins on cheeseshop c) due to a) I find it more annoying to script the install of single file plugins (you end up having to differentiate between the two types and take actions accordingly The main purpose of single file plugins is for developers to be able to hack up a quick plugin without having to think about setup.py and distutils/setuptools related options. > I actually think, that wether as egg or as one file, all the optional > plugins that come with the standard distribution should be installed > already, so that all that is necessary to use them is uncommenting > the respective lines in the default trac.ini file for activation and > configuration. Disk space is cheap, and this should all in all take > only a few hundred kb at most. Problems with this are: a) If I simply add tracext.* = enabled I get plugins that I may not want installed b) It's easier to add tracext.* = enabled and then simply install the subset of plugins I want, then adding an entry for each one c) It's not as simple as just uncommenting a line in the trac.ini because comments can't be kept in the ini file. The ConfigParser strips them. d) Explicit is better than implicit > No one is insisting on using tracext. as the namespace name. Although > I think it's the best fit. But what is the big problem when a few > plugins outside the main distribution use the same namespace? They had > to be installed first anyway, and even then conflicts are not too > likely, and if they occur, the onus to fix the problem is on the > plugin developer, since he wants it to work with trac. My point wasn't so much about using "tracext" itself. It was more about the "semi-blessed" nature of whatever namespace is chosen. If we choose a namespace to be "semi-blessed"/"semi-official" then we also need to set expectations of what we think should be in said namespace. Maintained, generally useful, no niche plugins, etc. (those are just ideas, not official reqs). Otherwise we'll have an issue where eveyone and their dog creates plugins in the tracext namespace, and then we get back to the issue with using tracext.* = enabled enabling too much. However, even then, it's better than the auto-install of included plugins since additional plugins would need to be manually installed. Additionally, if we create a semi-official namespace, I think we also need to give guidelines on how/where/when to use/choose a namespace. Perhaps even start a trachacks.* namespace. > That being said, I'm a proponent of allowing optional plugins to > become part of the main distribution. If a Plugin developer wants his > plugin to be included, he knows that brings new responsibilities and > requires more discipline, so it's up to him to decide that. This, of course, brings up the old issue of bloat vs minimalism. Part of the whole idea behind the component architecture was so that Trac core could be small and features could be added via plugins. I like the idea of encouraging plugin developers to get their plugins packaged with the main distribution. At least along the lines of raising code quality. However, I am against installing more stuff by default. I realize that disk space is cheap now. I find that to be a really lame reason for the "well let's just install everything and they can enable it later". How about we simply make it easy and clear for them to choose and install what they want? Previously there was talk about various packages: -core, -everything_under_the_sun. Ideally, we just have a really nice plugin management system. I realize that's a ways away atm. The nice thing about making egg based plugins and putting them in the cheesehop, is that one can simply run easy_install foo and it's done! Additionally, with things in the cheeseshop, we can simply add plugins to extras, etc. Again, I'm not against a semi-official namespace. I am against auto-installing non-core plugins. -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 -~----------~----~----~----~------~----~------~--~---
