Ilias Lazaridis wrote:
* vendors should be able to provide a "product" (collection of plugins
and related configuration)
Why can't a vendor simply ship additional plugins as is? As I see it,
in order for a vendor to create a "product" there are two options.
1. One, simply a set of packages that are installed along with trac
2. A trac install plus a host of plugins, plus a fully configured env
On point 1, I don't see why a vendor can't do that currently. Speaking
for gentoo experience (as that's what I'm most familiar with) I would
simply have the ebuild download and install extra plugins. Due to setup
utils, I wouldn't even have to install trac. I'd simply install a
plugin and it would automatically pull down the required version of trac.
On point 2, I don't think this is a job for trac to worry about. First,
it would require that trac take care of creating the database for the
environment. Obviously, it currently does this for sqlite, but there is
no clean way to do this for PostgreSQL (nor would many PostgreSQL admins
want it to). You're also assuming a lot about the configuration of the
web server, env file layout, etc. If a vendor really wants to do all
this, they can. Bash is a great language for this type of thing.
* trac should be able to work with an simple svn checkout.
While I'm not averse to this ability, I don't think that it's a show
stopper, or even one that really matters. Sure, it'd be neat, and maybe
it's just a simple byproduct of the other stuff, but most programs don't
simply work from a svn checkout.
Having a checkout/compile cycle is standard practice. Even then, once
it's setuptoolized, one will be able to simply say:
easy_install http://domain.com/path/to/repos
and have it install.
* Environment Inheritance should be multi-level, with the ability to
change the base environment manually.
This one I'm not sure I fully understand. If you're just talking about
config options, then it appears that cmlenz's proposal is sufficient.
Templates is a decent idea, though I think one level of inheritance
would be sufficient (unless it's trivial from there to extend it to N).
Cascading bunches of templates would probably get very confusing.
Ddefining one coherent theme for a group of trac sites easily would be
nice. However, I don't really see how this is that much different than
the ability to use site_* templates or override a default template by
moving a file with said name into the templates/ dir of the local env.
Now, if you're talking about inheriting config, templates, and database
content, then I think you're crazy. Mainly because inheriting database
content is much more along the lines of multi-project support. Trying
to cascade a bunch of databases together wouldn't be fun.
Many tiny changesets directly on trunk should be prefered, whenever
possible, thus development is kept trackable.
I see one big merge just as trac-able[1] as many small changes. I think
the main point was that the merge is a pain, and trying to do it in
small changes would result in more breakage of trunk, or much more work
to accommodate for the small changes.
-John
[1] Yes, pun intended.
--~--~---------~--~----~------------~-------~--~----~
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
-~----------~----~----~----~------~----~------~--~---
