So, I gave up on doing things within Trac, and combined the two approaches suggested earlier. My setup is documented here: https://github.com/drewbug/heroku-trac#protect-database-string
This even works when developing locally with *foreman*, which I'm happy about. It's probably a good idea for me to switch to *gunicorn*, rather than *tracd *, but I was aiming for the simplest functional product, not necessarily the fastest. Next up will be my adventures with AccountManagerPlugin<http://trac-hacks.org/wiki/AccountManagerPlugin/AuthStores#SessionStore>, which I'm hoping is easy. As for changes to the configuration file not persisting: I'm not too worried at the moment, but I'm not exactly able to come up with an idea on what the worst-case scenario would be. Ideas? If I run in to any more trouble, I'm sure I'll be back. Thanks for all the help, everyone. On Wednesday, October 16, 2013 9:41:38 AM UTC-4, Ethan Jucovy wrote: > > On Tue, Oct 15, 2013 at 11:44 PM, Drew Carey Buglione > <[email protected]<javascript:> > > wrote: > >> My reason for desiring to do things this way is simple: I'm running Trac >> on Heroku, where there is a convention of keeping all private or >> environment-specific data in config variables. >> >> I can not deploy any files to Heroku without checking them into version >> control, and I'd like to avoid checking my database string into version >> control. >> >> Heroku provides the database string as an environmental variable, though, >> so if anyone has any idea how I can go about resolving my problem the way >> I'd like to, I'd really appreciate some pointers. >> > > There's definitely no well supported way to do this, and a plugin wouldn't > really be the right approach for the reason Olemis mentioned (chicken/egg). > > > Building your own WSGI script that sets up the environment and then > overrides the relevant config variable before dispatching each request is > probably the best way to go. With a bit of tinkering and copying code > around from trac.web.main I was able to get something that at least appears > to work: > > https://gist.github.com/ejucovy/7007820 > > You can point gunicorn (or any other wsgi server) to it. It serves a > single Trac environment -- it assumes TRAC_ENV is present in an environment > variable; it would take some more work to make it > multi-environment-friendly. If you set a TRAC_DATABASE environment > variable, it will (non-persistently; just for the duration of each request) > override the database connection string from the environment's config file. > > It seems to work, but it's possible that it would run into problems > (unclosed database connections?) that aren't apparent at first glance. > > BTW, I've been thinking of moving some of my Trac sites over to Heroku, > but I was worried that Trac's assumptions about filesystem access for > environments would break under Heroku's model. I guess this is a topic for > another thread, but I'd love to hear more about how you're setting up each > Trac environment in Heroku and managing/versioncontrolling/deploying the > environment directories themselves. > > Best, > Ethan > -- You received this message because you are subscribed to the Google Groups "Trac Development" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. To post to this group, send email to [email protected]. Visit this group at http://groups.google.com/group/trac-dev. For more options, visit https://groups.google.com/groups/opt_out.
