John Hampton wrote:
> I'm fine with using the tracext.* namespace for additional plugins,
> however, I agree with Noah that we should make them real egg based
> plugins rather than single file plugins.
>
Well, making them systematically .egg based somehow defeats the
"simplicity" part of the whole approach.
But it all depends on the particular situation, in some cases the egg
based approach is more suited.
Like already said, the Mercurial plugin *has* to be maintained as an
external plugin, unfortunately.
Idem for the spamfilter, not for licensing reasons here, but because
it's much bigger and not that actively maintained. *If* it would have
been actively maintained, then it could have been placed directly below
tracext/. Likewise, if one day something we once bundled is not actively
maintained anymore, it could just be moved to some other place, kept in
the same namespace package but no longer bundled with Trac.
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.
> Part of my reason for this is that I have an irrational hatred for
> single file plugins.
We're not talking about making them single file plugins either, but more
having a parallel or alternative package to trac.
Within the "trac" package everything is enabled by default, whereas in
the "tracext" package (or "tracopt") everything is disabled by default.
> Don't ask for the reasons, cus they aren't really
> good. Suffice to say, I don't like them and I think they should be used
> as little as possible
>
Well, Remy presented some of the inconveniences of single file plugins,
in his initial mail.
> Second, single file plugins can't use some of the nice features such as
> install_requires (which you note could be useful for the plugins that
> require ConfigObj).
>
> 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.
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.
Therefore, first move optional things out of trac to tracext.
Candidates are:
- trac.versioncontrol.svn*
- trac.mimeview.{enscript,php,rst,silvercity,txtl}
- some of the sample-plugins
Then eventually add new things there, like a versioncontrol backend for
the filesystem (which otherwise I would probably have added to
trac.versioncontrol directly).
> Installing them would then require
> a) tracext.* = enabled or trac.foo = enabled
> b) easy_install foo or building from source
>
> I think this is better because:
> a) easy_install is fairly easy
>
When it works... (you and the plugin provider need to be online; 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).
> b) keeps what we install smaller
>
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.
> c) if one actually enables the full tracext.* namespace, then they
> don't inadvertently enable plugins that they didn't want but didn't know
> were installed.
>
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").
> 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.
>> Sure, and the quality and maintainability criterions are key points
>> here. Nevertheless I think this could eventually help to improve the
>> interaction between plugin developers and the Trac team. Plugin authors
>> developing "generally useful but optional functionality" could strive to
>> get their plugin included into tracext, and in order to meet the quality
>> criterions mentioned above, the end result could be only an increase in
>> the quality of the plugin, and a simpler way for the user to access the
>> extended feature, so a win on all accounts.
>>
>
> This brings up the question of "enforcement". In addition to the
> plugins already on trac-hacks.org that Tim mentioned, the
> ActiveDirectoryAuthPlugin also uses the tracext.* namespace.
>
> So, what are the rules/requirements/etc for using tracext.*?
>
> As we don't have any real way of enforcing which plugins use the
> namespace, I think this is another reason why the plugins shouldn't be
> installed automatically.
>
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.
The exact mechanism to be used for categorization and storing the
category metadata - help mainly - has yet to be defined, of course. I
think that tracext submodules could be used as categories and their
__init__.py files could contain such (translatable) help text.
Single file plugins and plugins not using the tracext namespace
themselves could simply say they belong to one of the existing
categories (e.g. category = 'trac.versioncontrol.backend', set as a
global value for a single file plugin, or as a PKG-INFO attribute for an
egg plugin).
-- Christian
--~--~---------~--~----~------------~-------~--~----~
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
-~----------~----~----~----~------~----~------~--~---
