Last modified: 2014-10-19 17:44:04 UTC
We have a lot of environment variables. It is becoming hard to document them all. Should we start using a tool like dotenv[1]? Looks like it is the most popular configuration management gem for Ruby[2]. 1: https://rubygems.org/gems/dotenv 2: https://www.ruby-toolbox.com/categories/Configuration_Management
I like the idea of using this in tandem with mw-vagrant since it would allow for extension-specific variables, but I'm not sure we should actually commit the .env file; it should be provisioned by puppet.
If we commit the .env file, we can get rid of some ugly hacks that we have at the moment. For example, the entire url_module.rb in mediawiki/selenium[1] and MobileFrontend[2]. 1: https://github.com/wikimedia/mediawiki-selenium/blob/master/lib/mediawiki_selenium/support/modules/url_module.rb 2: https://github.com/wikimedia/mediawiki-extensions-MobileFrontend/blob/master/tests/browser/features/support/modules/url_module.rb
We can get rid of those hacks (and we should!) regardless of our use of an `.env` file. As I understand it, this is more about simplifying setup outside of something like mw-vagrant where the environment variables are not set for you—i.e. it obviates the requirement to source environment variables into the current shell before executing cucumber. While I think simplification of setup is definitely a worthwhile goal, standalone use of mediawiki_selenium outside of mw-vagrant will become increasingly marginal as adoption of the latter picks up. If we commit the `.env` file, overriding it will be problematic—it will show up in people's git status—and it's utility within mw-vagrant becomes nil. What if we commit a `.env` to mediawiki_selenium but leave it out of extension repositories? That way we have a nice place to store global ENV defaults, but still allow for clean local overrides in mw-vagrant.
Sounds good to me!
