Hardcoded configuration values about figaro HOT 9 CLOSED

You could either put those in application.yml if you don't mind them being Git-ignored or you could just put them in application.rb or an initializer:

ENV['MY_PUBLIC_CONFIGURATION'] = 'somethingpublic'

Does that help?

from figaro.

I wish thinking there should be an option for Figaro to load in multiple .yml files. That way, I can store something like config.yml in revision control while application.yml contains my sensitive stuff and will be created manually on production. The API could possibly look like

Figaro.configure do |config|
  config.files = %w(application.yml config.yml)
end

Thoughts? Would you accept a pull request for this?

from figaro.

The problem with configuring Figaro is that it's kind of… too late. By the time the initializers run, Figaro's already done! That's what allows us to use Figaro-set configurations in other initializers. I would encourage you to set these in your own public, committed Ruby file or add them to application.yml. You could also roll your own solution (in application.rb to load in a config.yml file:

config_path = File.expand_path('../config/config.yml', __FILE__)
ENV.update(YAML.load_file(config_path)) if File.exist?(config_path)

from figaro.

What about a .figaro file? Just to keep things DRY and also take advantage of the environmental logic that's already built into Figaro.

application.yml
config.yml

from figaro.

Seems that having two configuration files would be repeating yourself, when the job can be done with one. In the past, I've committed an application.example.yml and that can include all sorts of content and comments regarding what values can stay and which still need to be added.

from figaro.

The two config files would have different roles. For example, application.yml would look like

SENDGRID_API_KEY: abcdefg

development:
    DATABASE_PASSWORD: yomomma

production: 
    DATABASE_PASSWORD: yodadda

and then config.yml would look like

USER_LOGIN_MAX_ATTEMPTS: 5
USER_SIGNUP_ENABLED: true
CONTACT_EMAIL:  [email protected]

They really shouldn't overlap, although application.yml if defined first within .figaro, should take precedence.

puts ENV["USER_LOGIN_MAX_ATTEMPTS"]  # 5

The application.example.yml is still useful, but only for application.yml since it's not commited to the repository. Say you would like to change the login max attempts, it seems like it would make more sense to commit that to repo rather than go to each of your production servers and change it manually.

from figaro.

Thoughts? 😄

from figaro.

This seems like unnecessary repetition.

By the way, instead of editing files directly on the server which aren't checked into version control, symlink them into a shared directory and use something like capistrano to upload the config. You can even have this run automatically every time you deploy.

after 'deploy:setup' do
  transfer :up, "config/application.yml", "#{shared_path}/application.yml", :via => :scp
end

before 'deploy:finalize_update' do
  run "ln -sf #{shared_path}/application.yml #{latest_release}/config/application.yml"
end

from figaro.

+1 for this. I often need to have shared and developer specific variables, having two configuration files would be good so I can check in the shared version.

from figaro.