7 ms·
At this point I think they are ready for a minor refactoring to name their code with what it's actually doing, ie. they aren't wrapping env, they are configurin
by josho 12y ago
At this point I think they are ready for a minor refactoring to name their code with what it's actually doing, ie. they aren't wrapping env, they are configuring their system, so let's have a Configuration class. For getting discrete values, this could look like:
num_retires = Configuration.retry_attempts_count
which could fail immediately if the ENV['RETRY_ATTEMPTS_COUNT'] is not set.
While for configuring boolean values, we could do something like:
show_confidant if Configuration.display_confidential_info?
Which could handle the extra care around true/false ENV parameter parsing by taking advantage of the question mark in the method name convention that Ruby has.
For bonus points wrap that into the existing Rails.application mechanism, so that it's an obvious place for new developers on the project to go to find app parameters.
- scoot 12y agoThis pretty much describes Figaro: https://github.com/laserlemon/figaro https://github.com/laserlemon/figaro (apart from being baked into Rails, that is...)
- josho 12y agoNice. I should have known to spend 5 minutes looking for a gem instead of writing a comment. I suppose the parent could have done the same before writing their ENV wrapping and a blog post. ;)
- sirn 12y agoIn Rails 4.1, you can actually use ERb in the `secrets.yml`, so something like this should works: defaults: &defaults secret_key_base: <%= ENV.fetch('SECRET_KEY_BASE') %> default_hostname: <%= ENV.fetch('DEFAULT_HOSTNAME') %> redis_url: <%= ENV.fetch(ENV['REDIS_PROVIDER'] || 'REDIS_URL') %> debug: <%= ENV.fetch('DEBUG') == "true" %> development: <<: *defaults production: <<: *defaults Though not as convenient as Figaro, I've been pretty happy with the setup so far.