Swappable Configuration implementations

[ethan.jucovy@…]

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 extending Configuration.save()to write out a diff from the previous file, or to commit changes directly to a repository in a subprocess.

See ​[Trac-dev] Setting database string from environmental variable?" for motivation.

[Ryan J Ollos]

One possibility might be to keep the file-based configuration and allow other configuration data sources to be specified as parents that can override the base configuration. This could be through the [inherit] section, where we currently only allow files to be specified as parents. A syntax with data source type as the prefix could allow the Configuration objects to be generated in a factory. For example, [inherit] source = osenv:trac_config, and trac_config might be an environment variable with JSON-structured content like Ethan suggested. There are many details to work out though, such as determining how the Configuration object knows to re-read the configuration data in absence of a file timestamp to check. At this point it looks like the Configuration class needs to be effectively redesigned to support data sources other than a file via ConfigParser.

[Ryan J Ollos]

See also related ticket #11675, which would help with deployment on platforms such as Heroku.

[Ryan J Ollos]

Replying to ethan.jucovy@…:

• Ensuring that trac.ini remains version-controlled by extending Configuration.save()to write out a diff from the previous file, or to commit changes directly to a repository in a subprocess.

Sending a notification on configuration change is another use-case that I'm interested in. We'll need an IConfigurationChangeListener ExtensionPoint. Configuration​ is not a Component though. At a minimum we will need to pass the Environment object to Configuration.

Once the extension point is implemented, an IConfigurationChangeListener can prepare a diff using the ​context_diff function in difflib and send a notification.

[Ryan J Ollos]

Discussion about configuring Trac for Docker using environment variables ​gmessage:trac-dev:09KHkId-deE/DsWHuZB52tkJ.

[Ryan J Ollos]

Narrowing focus for milestone:1.2. Please move ticket to milestone:1.2 if you intend to fix it.

[Peter Suter]

I just remembered I had this untested experimental patch​. Feel free to pick it up (or to start from scratch).

[Ryan J Ollos]

Milestone renamed

[Ryan J Ollos]

Milestone renamed