Opened 10 years ago
Last modified 3 years ago
#11339 new enhancement
Swappable Configuration implementations — at Initial Version
Reported by: | Owned by: | ||
---|---|---|---|
Priority: | normal | Milestone: | next-dev-1.7.x |
Component: | general | Version: | |
Severity: | normal | Keywords: | config |
Cc: | Jun Omae, Ryan J Ollos, mael.lavault@… | Branch: | |
Release Notes: | |||
API Changes: | |||
Internal Changes: |
Description
On some systems, it may be useful to initialize the Trac Environment with a non-standard Configuration object. Use cases include:
- Deploying Trac on Heroku with configuration from environment variables instead of
trac.ini
. Heroku provides an ephemeral filesystem; directly writing changes to files (vs. updating files locally in a git repository and pushing those changes to your Heroku instance) is risky, because those changes may disappear at any time (e.g. when redeploying code or when Heroku decides to reboot a system) and are not shared across application instances if you scale up your deployment. Meanwhile, Heroku *does* provide a persistent environment variable layer that can store up to 16kb of data. For a Heroku Trac deployment, a Configuration class that reads and writes its values via a JSON-structured environment variable would be more appropriate than a file-based configuration.
- Preventing through-the-web changes to the configuration altogether to ensure that formatting and comments in a hand-edited
trac.ini
are not lost, until #7378 is closed.
- Ensuring that
trac.ini
remains version-controlled by extendingConfiguration.save()
to write out a diff from the previous file, or to commit changes directly to a repository in a subprocess.
See this trac-dev thread for motivation.
Note:
See TracTickets
for help on using tickets.