Ticket #3905 (closed enhancement: worksforme)
Opened 5 years ago
Last modified 19 months ago
Introduce "parent_env" option within trac.ini
| Reported by: | ilias@… | Owned by: | jonas |
|---|---|---|---|
| Priority: | normal | Milestone: | |
| Component: | general | Version: | devel |
| Severity: | normal | Keywords: | consider |
| Cc: | |||
| Release Notes: | |||
| API 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
Change History
comment:1 Changed 5 years ago by ilias@…
comment:2 Changed 5 years ago by ilias@…
- Summary changed from Introduce "shared_dir" option within trac.ini to Introduce "parent_env" option within trac.ini
comment:3 Changed 5 years ago by ilias@…
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 Changed 5 years ago by cboos
- Keywords consider added
- Milestone set to 1.0
Well, maybe, I'm not completely opposed to that idea.
comment:5 Changed 4 years ago by osimons
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 Changed 4 years ago by cboos
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
comment:7 follow-up: ↓ 8 Changed 4 years ago by osimons
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 in reply to: ↑ 7 Changed 4 years ago by ilias@…
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:9 Changed 22 months ago by cboos
- Milestone changed from 1.0 to unscheduled
Milestone 1.0 deleted
comment:10 Changed 19 months ago by rblank
- Milestone triaging deleted
- Resolution set to worksforme
- Status changed from new to 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