Opened 18 years ago
Closed 14 years ago
#3905 closed enhancement (worksforme)
Introduce "parent_env" option within trac.ini
Reported by: | Owned by: | Jonas Borgström | |
---|---|---|---|
Priority: | normal | Milestone: | |
Component: | general | Version: | devel |
Severity: | normal | Keywords: | consider |
Cc: | Branch: | ||
Release Notes: | |||
API Changes: | |||
Internal Changes: |
Description
In order to allow an trac environment to inherit all the behaviour of another one, an "share_dir" option should be provided.
This will simplify multiple trac installations, especially within trac hosting environments.
It is unclear at this moment if this can be done in an non-intrusive way. If so, I'll provide the relevant patches.
context / further analysis:
Attachments (0)
Change History (10)
comment:1 by , 18 years ago
comment:2 by , 18 years ago
Summary: | Introduce "shared_dir" option within trac.ini → Introduce "parent_env" option within trac.ini |
---|
comment:3 by , 18 years ago
since setuptools-merge, see [4819], tge following option was introduced
[inherit] file = location of trac.ini file to use
A more flexible option would be (can be provided additionally):
[inherit] env = location of trac-environment to inherit
Initially, only the trac.ini would be used from the "env" (standard: env/conf/trac.ini).
In future, further things could be inherited from the environment, without the need to provide further entries for the ini-file
comment:4 by , 18 years ago
Keywords: | consider added |
---|---|
Milestone: | → 1.0 |
Well, maybe, I'm not completely opposed to that idea.
comment:5 by , 17 years ago
Apart from inheriting trac.ini settings that Trac already supports, I can't think of anything that would be useful to inherit in this manner ('further things'). And, with Trac architecture as it is, this would need to be strapped onto every feature that are going to interact with parent resources.
-1. Propose 'wontfix'.
comment:6 by , 17 years ago
Well, env
is maybe not the right name for this catch-all entry, as it wrongly suggests that everything from the env is inherited, which is not true of course.
But right now, there are 3 possible entries in the [inherit]
section:
file
plugins_dir
templates_dir
I guess when you want to make all 3 of them inherit from the same place, it make sense to think about having a shortcut, which is "future-proof" as well in case there are more inheritable things to come.
So instead of writing:
[inherit] file = /srv/trac/default/conf/trac.ini plugins_dir = /srv/trac/default/plugins templates_dir = /srv/trac/default/templates
it would be possible to have a shortcut like:
[inherit] * = /srv/trac/default
follow-up: 8 comment:7 by , 17 years ago
For configurations, I generally think "explicit is better than implicit" - and certainly in this important case where the actual options will not be found anywhere in either config.
On a the other side, supporting a wildcard can for sections can be useful for other config purposes. It could solve something much more concrete, namely how to better inherit or override [ticket-workflow]
sections. Currently, if there exists a 'default' workflow in inherited trac.ini, there is no useful way to override it as the project workflow will be a 'merge' as options can't be unset (ref. #3037). Inheriting in such sections should likely be 'all or none'.
Hmm. I'm much more unsure now.
comment:8 by , 17 years ago
Replying to osimons: …
Hmm. I'm much more unsure now.
You don't have too.
This enhancement simplifies advanced(!) multi-project setup (no one is forced to used it, like with every advanced feauture).
feel free to close this ticket, I implement it anyway into tracx (but it would be of benefit for other users).
comment:10 by , 14 years ago
Milestone: | triaging |
---|---|
Resolution: | → worksforme |
Status: | new → closed |
With respect to comment:6, the [inherit] file
option solves this issue already. You don't need to inherit plugins_dir
and templates_dir
separately, just put these options into the inherited .ini
file, and they will be picked up. It's also "future-proof", as all options are inherited.
depends on #3897