Am 07.02.2006 um 12:07 schrieb Christian Boos:
Christopher Lenz wrote:
Am 07.02.2006 um 09:38 schrieb Christian Boos:
On a related note, I was thinking about extending TRAC_ENV so
that it would
accept a _list_ of environment paths (e.g.
envpath1:envpath2:envpath3).
That would make it possible for mod_python to handle environment
in multiple
unrelated paths, like tracd can do.
I don't like this whole direction that the InterTrac merge opened
up: making the Trac core aware of foreign environments. That was
in fact the main concern I had with the merge, but was
unfortunately too busy to give timely feedback.
Before InterTrac, the only parts of Trac that were aware of the
environment parent directory, or multiple environments, were the
web front-ends. And there, it should be considered a rather ugly
temporary hack that is only in place as long as we don't have
multiple projects per environment. So I really don't want to see
the concept trickle into the core.
I would even suggest that we back out the sibling auto-detection
feature. Accessing one trac instance now means that all "sibling"
environments also get opened, which is a considerable performance
hit, in particular for CGI, that you have to pay even if you don't
need InterTrac links. How much work is it really to just put the
environments in the global configuration file?
Why environments should be hidden from each other?
I thought I had explained that, but well. The current multi-
environment support is only provided to make deployment easier,
similar to e.g. SVNParentPath. It's a hack limited to a single layer
that we provide because we don't yet support multiple project per
environment. As soon as we do support multiple projects per
environment, it is likely that we'll drop that support to reduce
complexity in code, configuration and documentation.
Multiple environments per interpreter are also problematic when it
comes to plugin support, because plugins can only be activated for
the complete interpreter. Furthermore, limiting the number of
environments to one per interpreter would allow us to make the
Environment object and all Components true singletons, further
simplifying the code. So this is the general long-term direction, and
adding features that conflict with that direction should obviously be
avoided.
The scope for Trac 1.0 is (and has always been) clearly limited to
single-project support. InterWiki/InterTrac links can help managing
multiple projects, however we should not try to bolt on more
comprehensive features such as retrieving and displaying information
from another environment.
So basically, IMNSHO this feature conflicts with the long-term
roadmap of Trac. Of course I would have preferred to discuss this
before the merge, which is why I was a bit pissed about the very
short time span you provided between proposal and merge.
Cheers,
Chris
--
Christopher Lenz
cmlenz at gmx.de
http://www.cmlenz.net/
_______________________________________________
Trac-dev mailing list
[email protected]
http://lists.edgewall.com/mailman/listinfo/trac-dev
