New top-level namespace "tracext"
Remy Blank
sample-plugins folder, next to a larger number of sample plugins that
only demonstrate some aspect of Trac programming.
More specifically, the authz_policy.py and extrapermissionprovider.py
plugins on trunk, and the commit_ticket_update.py plugin on multirepos,
provide generally useful functionality without requiring editing the
source code.
Until now, users had to extract these plugins from the source package or
download it from the repository browser, and install them in their
plugins folder. This makes it difficult to find out the exact version
that was used when reporting an issue, as $Revision$ tags are not
expanded in the repo browser. Moreover, they had to be updated manually
when upgrading Trac core.
I would like to move these plugins into a new top-level namespace
"tracext", similar to the "hgext" namespace used in Mercurial. Plugins
in tracext would be visible (that is, recorded in setup.py) but disabled
by default. They can therefore be enabled with a single entry in the
[components] section or through the "plugins" admin panel.
Obviously, I wouldn't want to move all plugins from sample-plugins into
tracext. I propose that the following criteria should be fulfilled for a
tracext candidate:
- The plugin should provide some self-contained, generally useful but
optional functionality.
- The plugin should not require editing the source code to be
configured for an install, but be usable as-is.
- The plugin should be actively maintained and tested regularly, and
its code quality should equate that of the trac namespace.
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.
Thoughts?
-- Remy
Noah Kantrowitz
This has been talked about in the past, and in general I think it is a bad idea. If you want to make them into proper egg'd plugins, then do that. The single-file plugin system was designed to make things easier, not more complex. 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.
--Noah
Remy Blank
> 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
Tim Hatch
>
> 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.
FYI (because nobody's brought it up): 'tracext' is already being used as
a namespace_package by the git plugin, mercurial plugin, and launchpage
plugin (which are proper setuptools-enabled plugins that specify entry
points for trac.plugins).
Tim
Remy Blank
> FYI (because nobody's brought it up): 'tracext' is already being used as
> a namespace_package by the git plugin, mercurial plugin, and launchpage
> plugin (which are proper setuptools-enabled plugins that specify entry
> points for trac.plugins).
I know. My understanding is that as long as they all define it as a
namespace and not a package, they can coexist peacefully.
OTOH, if there's a disadvantage to having them in the same namespace, we
can use another name. What about "tracopt" for "optional functionality"?
-- Remy
Christian Boos
I'm fully supportive to Remy proposal, which I think goes into the right
direction, as it echoes some older discussions for having a simpler way
to install and configure Trac out of the box, with a "minimal" setup
that could then be expanded through an improved plugins panel in the web
admin.
See e.g. http://groups.google.com/group/trac-dev/msg/97a217b2b21c52bf
and the follow-up from David Abrahams.
We also need to imagine a better way to "organize" the modules, instead
of the 2 level list of packages/components we have now.
Remy Blank wrote:
> We currently have a small number of directly useful plugins in the
> sample-plugins folder, next to a larger number of sample plugins that
> only demonstrate some aspect of Trac programming.
>
And beyond that, we have some non-essential components that could be
moved from trac.* to tracext.*.
In particular, with 0.12 and multirepos, there's no need we continue to
give a special status to the svn backend. We could move the svn related
support below tracext.svn, giving it parallel status as the other
backends. Unfortunately, the Mercurial plugin still needs to be
distributed separately, due to licensing reasons. In the future, we
could bundle the Git plugin for example, provided one of the core Trac
developer "adopts" such a beast ;-)
> More specifically, the authz_policy.py and extrapermissionprovider.py
> plugins on trunk, and the commit_ticket_update.py plugin on multirepos,
> provide generally useful functionality without requiring editing the
> source code.
>
Note that the authz_policy.py introduces an extra dependency
(ConfigObj), so we need some additional logic to handle such cases (same
thing for svn support, of course).
> Until now, users had to extract these plugins from the source package or
> download it from the repository browser, and install them in their
> plugins folder. This makes it difficult to find out the exact version
> that was used when reporting an issue, as $Revision$ tags are not
> expanded in the repo browser. Moreover, they had to be updated manually
> when upgrading Trac core.
>
> I would like to move these plugins into a new top-level namespace
> "tracext", similar to the "hgext" namespace used in Mercurial. Plugins
> in tracext would be visible (that is, recorded in setup.py) but disabled
> by default. They can therefore be enabled with a single entry in the
> [components] section or through the "plugins" admin panel.
>
> Obviously, I wouldn't want to move all plugins from sample-plugins into
> tracext. I propose that the following criteria should be fulfilled for a
> tracext candidate:
>
>
> - The plugin should provide some self-contained, generally useful but
> optional functionality.
>
I'm not sure "self-contained" is that pertinent. I can imagine some
optional features that depend on some other optional features ... e.g.
the svn property renderers depending on the svn backend.
> - The plugin should not require editing the source code to be
> configured for an install, but be usable as-is.
>
> - The plugin should be actively maintained and tested regularly, and
> its code quality should equate that of the trac namespace.
>
> 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.
>
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.
The recently discussed "filesystem" version control backend recently
discussed on th-users list is also a good candidate for tracext ;-) (see
https://lists.trac-hacks.org/pipermail/th-users/2009-October/000080.html).
-- Christian
John Hampton
> And beyond that, we have some non-essential components that could be
> moved from trac.* to tracext.*.
> In particular, with 0.12 and multirepos, there's no need we continue to
> give a special status to the svn backend. We could move the svn related
> support below tracext.svn, giving it parallel status as the other
> backends. Unfortunately, the Mercurial plugin still needs to be
> distributed separately, due to licensing reasons. In the future, we
> could bundle the Git plugin for example, provided one of the core Trac
> developer "adopts" such a beast ;-)
I have semi-officially taken over maintenance for the GitPlugin. I have
spoken to hvr and he's happy for me to do so as he's not using it much
anymore. Unfortunately, I haven't had as much time as I'd like to apply
many of the patches that are outstanding (such as 2.4 compatibility).
Fortunately, I should be able to dedicate more time on it in about a month.
>> I would like to move these plugins into a new top-level namespace
>> "tracext", similar to the "hgext" namespace used in Mercurial. Plugins
>> in tracext would be visible (that is, recorded in setup.py) but disabled
>> by default. They can therefore be enabled with a single entry in the
>> [components] section or through the "plugins" admin panel.
>>
>> Obviously, I wouldn't want to move all plugins from sample-plugins into
>> tracext. I propose that the following criteria should be fulfilled for a
>> tracext candidate:
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.
Part of my reason for this is that I have an irrational hatred for
single file plugins. 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
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. 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
b) keeps what we install smaller
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.
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)
> 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.
-John
Jan Schukat
think there are some misunderstandings.
On 15.10.2009, at 18:25, 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.
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.
>
> 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. Installing them would then require
> a) tracext.* = enabled or trac.foo = enabled
> b) easy_install foo or building from source
>
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.
>
> 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.
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.
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.
Regard
Jan
John Hampton
> 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
Christian Boos
> 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
John Hampton
> 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
Jan Schukat
1. you like using easy install more than using a web admin or typing a
config line
2. You want to be able to type tracext.* and then just use
easy_install, because you like easy_install
3. So you want to use easy_install instead of configuration to enable
or disable features
To all those objections there is one thing to say: the whole point of
the change was to avoid installation and to be able to configure
optional but common features. And you need to configure most of the
time anyway, so why introduce an additional step?
Now on reading this again, this sounds more smug and sarcastic than I
intended. Sorry for that. I just tried to point out your self-
admitted irrationality here. Feel free to bash me back :)
Regards
Jan
Remy Blank
> I have semi-officially taken over maintenance for the GitPlugin.
Hey, that's great!
> Part of my reason for this is that I have an irrational hatred for
> single file plugins. 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
I understand the feeling, mostly because I have the same feelings for
eggs, though less intense it seems ;-)
> I think this is better because:
> a) easy_install is fairly easy
Sure, easy_install is... well, easy, but no_install_at_all is even easier.
> 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.
I would rather discourage such practice.
> 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.*?
I realize now, after re-reading my original post, that my proposal was
confusing, probably also due to the disproportionate length of the post
compared to the simplicity of the proposal. So let me try to reformulate.
There are three very useful, but optional features packaged with Trac.
Activating and updating them is more difficult and error prone than
strictly necessary. My goal was simply to move them from one folder
(sample-plugins) to another (tracext), and to mark that folder as a
namespace. That was all.
The fact that they are currently packaged as single-file plugins is not
really relevant. All I wanted is that they can be enabled with a single
line in trac.ini, or through the plugin admin panel.
I proposed "tracext" as an analogy to "hgext", but I realize that this
brought more confusion, and suggesting that it should be a namespace
added even more.
And the "quality" criteria I mentioned were only intended to explain why
these three files should be moved from "sample-plugins" and not the others.
So maybe at this point I should retract the "tracext" namespace, and
instead suggest we move them to a new "tracopt" top-level *package*, or
a "trac.opt" package whose components would be disabled by default. This
will avoid any conflicts with external plugins while still reaching my
goal. Yes, that sounds like the simplest solution.
-- Remy
John Hampton
> Now on reading this again, this sounds more smug and sarcastic than I
> intended. Sorry for that. I just tried to point out your self-
> admitted irrationality here. Feel free to bash me back :)
Here comes the bashing! :) Actually, I don't want to interpreted as
bashing. I welcome the discussion and the opportunity to explain
myself. It is obvious that I didn't do a good job of explaining my
position to begin with.
> 1. you like using easy install more than using a web admin or typing a
> config line
Partly. The web admin is completely useless for installing plugins.
It's semi-functional for enabling/disabling components. However,
enabling/disabling plugins usually also means a restart of the server
(tracd, apache, whatever), so you're going to be on the command line
anyway. I don't like more-than-is-necessary stuff in the webadmin. I'd
rather have the option of installing something, than just leaving
something disabled.
> 3. So you want to use easy_install instead of configuration to enable
> or disable features
To install features, yes.
> To all those objections there is one thing to say: the whole point of
> the change was to avoid installation and to be able to configure
> optional but common features. And you need to configure most of the
> time anyway, so why introduce an additional step?
So, the real question is how common the usage is. Personally, I've
never used any of the sample plugins. Obviously, I'm not *most people*.
However, without any data it's impossible to actually decide whether or
not they are commonly used. Closely related, and generally useful?
Sure. Commonly used? Don't know.
Ideally, I'd like to see the *alternatives* stuff, such as version
control backends, database backends, etc. stay in trac proper.
Other stuff that is generally useful, I'd like to see in a separate
package (regardless of namespace, etc). I'd like to see a super easy
way to install (ideally this would be a revamped webadmin), and clear
documentation on what we like, things we think are good quality, and
clear documentation/explanations of what they do.
-John
John Hampton
> So maybe at this point I should retract the "tracext" namespace, and
> instead suggest we move them to a new "tracopt" top-level *package*, or
> a "trac.opt" package whose components would be disabled by default. This
> will avoid any conflicts with external plugins while still reaching my
> goal. Yes, that sounds like the simplest solution.
I think that trac.opt with them being disabled is probably the best atm.
-John
Remy Blank
> 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
Jan Schukat
On 15.10.2009, at 23:40, John Hampton wrote:
>
> So, the real question is how common the usage is. Personally, I've
> never used any of the sample plugins. Obviously, I'm not *most
> people*.
> However, without any data it's impossible to actually decide whether
> or
> not they are commonly used. Closely related, and generally useful?
> Sure. Commonly used? Don't know.
>
> Ideally, I'd like to see the *alternatives* stuff, such as version
> control backends, database backends, etc. stay in trac proper.
>
The most likely reason you didn't use any of the sample plugins was,
that it is too hard to install and enable them. Which is the whole
point of this proposal. Avoid installation of stuff that should be in
in the distribution anyway, and make enabling it easy.
But in Remy's last mail we all came to an agreement it seems.
Jan
Eli
> John Hampton wrote:
> > 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.
Eli: Except for the CGI case, right?
CHORUS: don't use cgi
Eli: Yes, yes, I kn-
CHORUS: Don't use CGI
Eli: -ow that, even evil_twin knows-
CHORUS: DON'T use CGI
Eli: that. I'm not suggesting to
CHORUS: DON'T USE CGI
Eli: use CGI, I'm just being
CHORUS: [throwing vegetables] DON'T USE CGI
Eli: pedantic...
CHORUS: [picking up rotten vegetables]
Eli: [flees]
Eli
------------------. "If it ain't broke now,
Eli Carter \ it will be soon." -- crypto-gram
retr...@gmail.com `-------------------------------------------------
John Hampton
> The most likely reason you didn't use any of the sample plugins was,
> that it is too hard to install and enable them. Which is the whole
> point of this proposal. Avoid installation of stuff that should be in
> in the distribution anyway, and make enabling it easy.
Actually, it's because I've never had any use for them
> But in Remy's last mail we all came to an agreement it seems.
But yes, we have reached an agreement.
-John
Erik Bray
>
> On Thursday 15 October 2009 4:56:15 pm Remy Blank wrote:
>> John Hampton wrote:
>> > 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.
>
> Eli: Except for the CGI case, right?
> CHORUS: don't use cgi
> Eli: Yes, yes, I kn-
> CHORUS: Don't use CGI
> Eli: -ow that, even evil_twin knows-
> CHORUS: DON'T use CGI
> Eli: that. I'm not suggesting to
> CHORUS: DON'T USE CGI
> Eli: use CGI, I'm just being
> CHORUS: [throwing vegetables] DON'T USE CGI
> Eli: pedantic...
> CHORUS: [picking up rotten vegetables]
> Eli: [flees]
>
> Eli
That just made my day! Now I don't feel quite as bad for being stuck
at work at 7:00 on a Friday.