4 ms·
I've thought about this particular issue quite a bit as well, but I haven't been able to come up with a great solution, because RAILS_ENV/RACK_ENV is ubiquitous
by dasil003 11y ago
I've thought about this particular issue quite a bit as well, but I haven't been able to come up with a great solution, because RAILS_ENV/RACK_ENV is ubiquitous and auto-detected by tools. So you can have multiple deployment targets running the same mode, but then you can't differentiate them by default in tools like New Relic, Slack, Honeybadger, etc. You can put a lot of effort into building custom solutions to this, but since there is no standard it's easy to run into brick walls. In the end I've found it to be more work than just adding a new RAILS_ENV setting across all the config files. Ugly but pragmatic.
- s_kilk 11y agoI think the lesson here is to not fuck it up in the first place. When inventing the new framework "Foo", call the variable FOO_DEBUG, not FOO_ENV. As you've observed, it's not really possible to go back and fix this kind of mistake after it's been made.