id,summary,reporter,owner,description,type,status,priority,milestone,component,version,severity,resolution,keywords,cc,branch,changelog,apichanges,internalchanges 11339,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 [https://devcenter.heroku.com/articles/dynos#ephemeral-filesystem 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 [https://devcenter.heroku.com/articles/config-vars 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 [[https://groups.google.com/d/topic/trac-dev/z4-gWs269X4|[Trac-dev] Setting database string from environmental variable?""]] for motivation.",enhancement,new,normal,next-dev-1.7.x,general,,normal,,config,Jun Omae Ryan J Ollos mael.lavault@…,,,,