laserlemon / figaro Goto Github PK

It might be useful to include a figaro:install Rails generator to add config/application.yml to .gitignore and to add an example application.yml file at config/application.example.yml. The example configuration file could include commented instructions for building the YAML and suggestions for what sort of information to include.

I am trying to use figaro and cannot seem to figure out why this would blow up:

development:
  HELLO: "developers"
test:
  HELLO: "testers"
production:
  HELLO: "users"

Using ruby-1.9.3-p327

Hi,

I wonder why RAILS_ENV is used instead of RACK_ENV when pushing to heroku, as the latter is the standard config key used throughout Cedar. Figaro's current implementation requires the user to add a redundant config key to the stack (heroku config:add RAILS_ENV={same-as-RACK_ENV}) before using the rake task.

Could you add CHANGELOG - at least from the current version?

Hi,
I'm using figaro to set my env variables in heroku and it is very useful.
Now I'm facing with the following necessity:
I've an app that is deployed in production into two different herokuapps, that is, I usually deploy it into a "app-one" server, and then after some testing I'll push it into the "app-two" app. So what I'd like is that into the application.yml I can filter automatically the environmental variables depending on the app that I'm pushing, i.e. something like

<% if :app == "app-one" %>
VAR_1: abra
VAR_2: cadabra
<% elsif :app == "app-two" %>
VAR_1: foo
VAR_2: bar
<% end %>

how can I handle this with Figaro?
Thanks

Since I'm using the heroku toolbelt instead of the gem, I was originally getting the following error:

~ $ rake figaro:heroku
There was an error in your Gemfile, and Bundler cannot continue.
There was an error in your Gemfile, and Bundler cannot continue.

After installing the gem (ignoring deprecation warnings):

~ $ rake figaro:heroku
production
rake aborted!
can't convert true into String

config/application.yml Note: This is working in development

# Application Configuration Variables
TWITTER_CONSUMER_KEY: 'XXXXXXXXXXX'
TWITTER_CONSUMER_SECRET: 'XXXXXXXXXXXXXXXX'
development:
  FACEBOOK_APP_ID: 'XXXXXXXXXXXX'
  FACEBOOK_APP_SECRET: 'XXXXXXXXXXXXXXXXXXXX'
production:
  FACEBOOK_APP_ID: 'XXXXXXXXXXXX'
  FACEBOOK_APP_SECRET: 'XXXXXXXXXXXXXXXXXXXX'

The error with trace:

~ $ rake figaro:heroku --trace
** Invoke figaro:heroku (first_time)
** Invoke environment (first_time)
** Invoke disable_rails_admin_initializer (first_time)
** Execute disable_rails_admin_initializer
** Execute environment
** Execute figaro:heroku
production
rake aborted!
can't convert true into String
/Users/emily/.rvm/gems/ruby-1.9.3-p194@ehip_news/gems/railties-3.2.8/lib/rails.rb:86:in `initialize'
/Users/emily/.rvm/gems/ruby-1.9.3-p194@ehip_news/gems/railties-3.2.8/lib/rails.rb:86:in `new'
/Users/emily/.rvm/gems/ruby-1.9.3-p194@ehip_news/gems/railties-3.2.8/lib/rails.rb:86:in `env='
/Users/emily/.rvm/gems/ruby-1.9.3-p194@ehip_news/gems/figaro-0.5.0/lib/figaro/tasks.rake:6:in `block (2 levels) in <top (required)>'
/Users/emily/.rvm/gems/ruby-1.9.3-p194@global/gems/rake-0.9.2.2/lib/rake/task.rb:205:in `call'
/Users/emily/.rvm/gems/ruby-1.9.3-p194@global/gems/rake-0.9.2.2/lib/rake/task.rb:205:in `block in execute'
/Users/emily/.rvm/gems/ruby-1.9.3-p194@global/gems/rake-0.9.2.2/lib/rake/task.rb:200:in `each'
/Users/emily/.rvm/gems/ruby-1.9.3-p194@global/gems/rake-0.9.2.2/lib/rake/task.rb:200:in `execute'
/Users/emily/.rvm/gems/ruby-1.9.3-p194@global/gems/rake-0.9.2.2/lib/rake/task.rb:158:in `block in invoke_with_call_chain'
/Users/emily/.rvm/rubies/ruby-1.9.3-p194/lib/ruby/1.9.1/monitor.rb:211:in `mon_synchronize'
/Users/emily/.rvm/gems/ruby-1.9.3-p194@global/gems/rake-0.9.2.2/lib/rake/task.rb:151:in `invoke_with_call_chain'
/Users/emily/.rvm/gems/ruby-1.9.3-p194@global/gems/rake-0.9.2.2/lib/rake/task.rb:144:in `invoke'
/Users/emily/.rvm/gems/ruby-1.9.3-p194@global/gems/rake-0.9.2.2/lib/rake/application.rb:116:in `invoke_task'
/Users/emily/.rvm/gems/ruby-1.9.3-p194@global/gems/rake-0.9.2.2/lib/rake/application.rb:94:in `block (2 levels) in top_level'
/Users/emily/.rvm/gems/ruby-1.9.3-p194@global/gems/rake-0.9.2.2/lib/rake/application.rb:94:in `each'
/Users/emily/.rvm/gems/ruby-1.9.3-p194@global/gems/rake-0.9.2.2/lib/rake/application.rb:94:in `block in top_level'
/Users/emily/.rvm/gems/ruby-1.9.3-p194@global/gems/rake-0.9.2.2/lib/rake/application.rb:133:in `standard_exception_handling'
/Users/emily/.rvm/gems/ruby-1.9.3-p194@global/gems/rake-0.9.2.2/lib/rake/application.rb:88:in `top_level'
/Users/emily/.rvm/gems/ruby-1.9.3-p194@global/gems/rake-0.9.2.2/lib/rake/application.rb:66:in `block in run'
/Users/emily/.rvm/gems/ruby-1.9.3-p194@global/gems/rake-0.9.2.2/lib/rake/application.rb:133:in `standard_exception_handling'
/Users/emily/.rvm/gems/ruby-1.9.3-p194@global/gems/rake-0.9.2.2/lib/rake/application.rb:63:in `run'
/Users/emily/.rvm/gems/ruby-1.9.3-p194@global/gems/rake-0.9.2.2/bin/rake:33:in `<top (required)>'
/Users/emily/.rvm/gems/ruby-1.9.3-p194@global/bin/rake:19:in `load'
/Users/emily/.rvm/gems/ruby-1.9.3-p194@global/bin/rake:19:in `<main>'
/Users/emily/.rvm/gems/ruby-1.9.3-p194@ehip_news/bin/ruby_noexec_wrapper:14:in `eval'
/Users/emily/.rvm/gems/ruby-1.9.3-p194@ehip_news/bin/ruby_noexec_wrapper:14:in `<main>'
Tasks: TOP => figaro:heroku

Figaro is great to configure private settings, but it would be great if it could also support non-private settings that can be safely committed a VCS

I am receiving the following error with two custom environments (test, staging):

09:32:40 web.1    | I, [2013-05-06T09:32:40.236153 #48177]  INFO -- : Refreshing Gem list
09:32:52 worker.1 | rake aborted!
09:32:52 worker.1 | (<unknown>): mapping values are not allowed in this context at line 30 column 20
09:32:52 worker.1 | /Users/m/.rvm/gems/ruby-1.9.3-p327/gems/figaro-0.6.3/lib/figaro.rb:21:in `raw'
09:32:52 worker.1 | /Users/m/.rvm/gems/ruby-1.9.3-p327/gems/figaro-0.6.3/lib/figaro.rb:17:in `env'
09:32:52 worker.1 | /Users/m/.rvm/gems/ruby-1.9.3-p327/gems/figaro-0.6.3/lib/figaro/railtie.rb:7:in `block in <class:Railtie>'
09:32:52 worker.1 | /Users/m/.rvm/gems/ruby-1.9.3-p327/gems/activesupport-3.2.13/lib/active_support/lazy_load_hooks.rb:34:in `call'
09:32:52 worker.1 | /Users/m/.rvm/gems/ruby-1.9.3-p327/gems/activesupport-3.2.13/lib/active_support/lazy_load_hooks.rb:34:in `execute_hook'
09:32:52 worker.1 | /Users/m/.rvm/gems/ruby-1.9.3-p327/gems/activesupport-3.2.13/lib/active_support/lazy_load_hooks.rb:43:in `block in run_load_hooks'
09:32:52 worker.1 | /Users/m/.rvm/gems/ruby-1.9.3-p327/gems/activesupport-3.2.13/lib/active_support/lazy_load_hooks.rb:42:in `each'
09:32:52 worker.1 | /Users/m/.rvm/gems/ruby-1.9.3-p327/gems/activesupport-3.2.13/lib/active_support/lazy_load_hooks.rb:42:in `run_load_hooks'
09:32:52 worker.1 | /Users/m/.rvm/gems/ruby-1.9.3-p327/gems/railties-3.2.13/lib/rails/application.rb:67:in `inherited'

The syntax for the yml file is fine and can be loaded elsewhere.

Any ideas?

Hi,

(This is my first issue report ever.)

I'm running the rake task to set ENV variables on Heroku, and I noticed that it'snot treating special characters well:

my secret is: 'xxxxx+xxx'

buy Heroku config tells me that it was set to: 'xxxxx+xxx', so there's something going on with escaping.

Best regards,
Tamas

Given following application.yml:

VAR1: one
VAR2:

Figaro behaves like this:

ENV["VAR1"] #=> "one"
Figaro.env.var1 #=> "one"

ENV["VAR2"] #=> nil
Figaro.env.var2 #=> raises NoMethodError

ENV["VAR3"] #=> nil
Figaro.env.var3 #=> raises NoMethodError

I believe both Figaro.env.var2 and Figaro.env.var3 should behave coherently with ENV[] and return nil in those cases.

However, I'm actually using the Figaro.env approach in few initializers because I want to ensure that some variable is set and I prefer to crash my app to crash at boot time to tell me what's wrong. That's why I propose introducing bang methods so that:

ENV["VAR2"] #=> nil
Figaro.env.var2 #=> nil
Figaro.env.var2! #=> raises Figaro::UnsetError instead of meaningless NoMethodError

I'd attach code with pleasure but I wanted to discuss it first. I consider this change as a breaking one. I believe I'm not alone in using Figaro.env syntax to force crash when env variable is not provided and all those people would have to introduce changes in their applications.

Not really an issue, but I need some advice.

In creating a payment engine with Stripe Connect, each created project through Oauth has its own Stripe secret key which is save to the database as project.stripe_key which will be used to create a Stripe charge.

I would like to use Figaro to call project.stripe_key from the webform to make it as easy as possible for users of the engine to configure their app. Any suggestions on how to load it into the application.yml?

I have:
STRIPE_SECRET_KEY: "<%= project.stripe_key %>"

With:
<script src="https://checkout.stripe.com/v2/checkout.js" class="stripe-button" data-key="<%= ENV['stripe_secret_key'] %>" data-label="Contribute With Stripe"></script>

in the checkout button of my .erb file. Thanks so much..

The rake task doesn't parse the application.yml correctly. It is not following the YAML syntax. It finds variables that are not indentd, but ones that follows the YAML syntax it doesn't find.

EX:

ADMIN_NAME: foo
ADMIN_EMAIL: [email protected]

development:
  SOME_VAR: 0.0.0.0
  DATABASE_URL: mongo://localhost:27628/dev-database

when running RAILS_ENV=development rake figaro:heroku it will push the ADMIN_NAME and ADMIN_EMAIL to heroku but not the ones specified under development. Is this a bug or do I have something wrong in my configuration somewhere?

Figaro loads it's environment variables before the test_helper.rb runs. test_helper.rb has ENV["RAILS_ENV"] = "test" as it's first line but by the time it gets there the database.yml has already been populated with my development config information, not my test config information.

This causes the tests to be run against the development database.

I need to add private github gem into Gemfile. The easiest way to do that is to put git login & pass into git path.

I've added git credentials into config/application.yml, but they are not available in Gemfile. Is there any workaround?

I have the following in application.yml

development:
  IS_IT_TRUE: false

However, when I access it from Figaro environment, the returned value is a string

2.0.0p0 :001 > Figaro.env.is_it_true
 => "false"

With RubyGems.org being hacked today using the psych exploit, I'm wondering how safe the application.yml files are when deploying to a production server other than Heroku?

Here's a link to the HN discussion about the hack where qrush explains that the intruders copied and pasted the contents of config/initializers/* and config/*.yml to Pastie:
https://news.ycombinator.com/item?id=5139583

Now that Rails 4.1 does 50% of what figaro does it might be smart to remove that for a major version release and focus on the other parts of the gem.

I wanted to create something like the following but wasn't able to.

ADMINS:
 admin1:
   - name
   - password
 admin2:
   - name
   - password

It looks like Figaro ignores hashes other than the Rails.env key. Is there a better way to accomplish this with Figaro? I've settled on just flattening the values for now.

NUM_OF_ADMINS: 2
ADMIN_1_NAME:
ADMIN_1_PASSWORD:
ADMIN_2_NAME:
ADMIN_2_PASSWORD:

Having a data structure would make it easier for me to seed admins since I could just iterate over the elem/keypairs. Instead I have to explicitly state the number of admins to create and my iteration code isn't very pretty.

gem version 0.7.0

When I run the above command

rake figaro:heroku[appname]
no matches found: figaro:heroku[appname]

Will this gem work with Sinatra?

bundle exec rake figaro:heroku configures Heroku improperly with development environment values, though config/application.yml is set up exactly as prescribed:

HELLO: world
development:
  HELLO: developers
production:
  HELLO: users

I am aware that README suggests setting RAILS_ENV.

Already, Heroku's RAILS_ENV is set correctly (to 'production'), so this value should be accessible:

$ heroku run rails console
> ENV['RAILS_ENV']
=> "production"

Oddly, bundle exec rake figaro:heroku works correctly, after doing heroku config:set RAILS_ENV=production.

Even without that, doing bundle exec rake figaro:heroku RAILS_ENV=production instead will also work.

But IMO these ways aren't as good, and shouldn't be necessary.

I like this gem.
And I would like use it in other (not Rails) frameworks, ex Sinatra.
Do you have plan to support it?

I'm getting the following error when running rake -T, this happened after the update to the version 0.6.0. Any idea of what may be the problem?

Thanks!

can't convert false into String
/home/eticus/.rvm/gems/ruby-1.9.3-p327/gems/figaro-0.6.0/lib/figaro/railtie.rb:7:in `update'
/home/eticus/.rvm/gems/ruby-1.9.3-p327/gems/figaro-0.6.0/lib/figaro/railtie.rb:7:in `block in <class:Railtie>'
/home/eticus/.rvm/gems/ruby-1.9.3-p327/gems/activesupport-3.2.11/lib/active_support/lazy_load_hooks.rb:34:in `call'
/home/eticus/.rvm/gems/ruby-1.9.3-p327/gems/activesupport-3.2.11/lib/active_support/lazy_load_hooks.rb:34:in `execute_hook'
/home/eticus/.rvm/gems/ruby-1.9.3-p327/gems/activesupport-3.2.11/lib/active_support/lazy_load_hooks.rb:43:in `block in run_load_hooks'
/home/eticus/.rvm/gems/ruby-1.9.3-p327/gems/activesupport-3.2.11/lib/active_support/lazy_load_hooks.rb:42:in `each'
/home/eticus/.rvm/gems/ruby-1.9.3-p327/gems/activesupport-3.2.11/lib/active_support/lazy_load_hooks.rb:42:in `run_load_hooks'
/home/eticus/.rvm/gems/ruby-1.9.3-p327/gems/railties-3.2.11/lib/rails/application.rb:67:in `inherited'
/home/eticus/workspaces/ix-workspace/app-generator-sever/config/application.rb:10:in `<module:AppGeneratorServer>'
/home/eticus/workspaces/ix-workspace/app-generator-sever/config/application.rb:9:in `<top (required)>'
/home/eticus/workspaces/ix-workspace/app-generator-sever/Rakefile:4:in `require'
/home/eticus/workspaces/ix-workspace/app-generator-sever/Rakefile:4:in `<top (required)>'
/home/eticus/.rvm/gems/ruby-1.9.3-p327/bin/ruby_noexec_wrapper:14:in `eval'
/home/eticus/.rvm/gems/ruby-1.9.3-p327/bin/ruby_noexec_wrapper:14:in `<main>'

Not really an issue.
Is there any reason for allowing only single string values for ENV ?
I was trying to set an ENV['COUNTRIES'] as an array of country names using standard yml syntax in application.yml, but figaro always returns a .to_s version of the array.
I understand it wouldn't be possible to pass a ruby string as a shell ENV variable, but why preventing to do this on the yml file ? Consistency ?

Would figaro work for Padrino without adding specific Padrino.env code?

Is this the case or am I missing something?

See my application.yml :

development:
  AWS_BUCKET: xxx
  AWS_ACCESS_KEY_ID: xxx
  AWS_SECRET_ACCESS_KEY: xxx
  DEV_DB_NAME: xxx
  DEV_DB_USERNAME: 'xx'
  DEV_DB_PASSWORD: "'xxx'"
test:
  TEST_DB_NAME: xxx
  TEST_DB_USERNAME: 'xx'
  TEST_DB_PASSWORD: "'xxx'"

And here is my database.yml :

development:
  adapter: postgresql
  encoding: unicode
  database: <%= ENV['DEV_DB_NAME'] %>
  pool: 5
  username: <%= ENV['DEV_DB_USERNAME'] %>
  password: <%= ENV['DEV_DB_PASSWORD'] %>
  template: template0

test:
  adapter: postgresql
  encoding: unicode
  database:  <%= ENV['TEST_DB_NAME'] %>
  pool: 5
  username: <%= ENV['TEST_DB_USERNAME'] %>
  password:  <%= ENV['TEST_DB_PASSWORD'] %>
  template: template0

Eventhough all ENV variables set inside application.yml are accessible from console or whole application, they don't work in two cases:

1. rails db : It does not connect to DB because can't read ENV variables.
2. In the test environment. When I try to run my tests, test DB is not accessible due to no password.

I love the mascot - but he should be at the top of the readme, not the bottom, IMHO :(

PS Figaro looks like a useful too :)

I can't use Figaro inside Guardfile. When I do

require 'figaro'
Figaro.env.something

it raises

#<NoMethodError: undefined method `join' for nil:NilClass>
/lib/figaro.rb:29:in `path'

because Rails.root isn't loaded yet. Figaro should require all it's dependencies.

Hi!

First, thank you for this. We see this problem a lot with Diaspora and deploying to Heroku, but also all of the other crazy ways people deploy the app.

I think this would fix many of the problems we are having. One feature I really like from SettingsLogic is support for overrides in each rails enviroment

ie you can put things in a :development or :production name space, and they are mashed into the top level settings, overriding any nonspecific setting with the same name.

I'd be in to contributing, or getting one of our contributors to make it happen. Would you have any preferences to how this feature could get coded?

I have a Rails 3 app deployed on Amazon's Elastic Beanstalk solution. When I'm developing locally, my ENV variables defined in config/application.yml are set correctly; however, they're non-existent in production. This gem isn't only for Heroku deployment, correct? Has anyone used this gem in EB (Elastic Beanstalk)? If so, were there any gotchas to get it to work?

Thanks!

bundle exec rake figaro:heroku gives a spurious RubyVersionMismatch error for the latest Figaro and Bundler versions on Ruby 1.9.3 (locally and on Heroku).

heroku run bundle exec rake db:reset works fine, however.

EDIT: bundle exec rake db:reset works fine, too.

A tiny (Rails) test app fails.

Rubygems.org figaro doesn't specify Ruby 1.9.2, nor does README.

It doesn't get the error if the Heroku app is running Ruby 1.9.3, but Ruby 1.9.2 is running locally.

EDIT: It doesn't get the error when Ruby 1.9.2 is running locally, and the Heroku app is running Ruby 1.9.3.

Here's the error output (yes, it comes out doubled):

$ bundle exec rake figaro:heroku --trace
** Invoke figaro:heroku (first_time)
** Invoke environment (first_time)
** Execute environment
** Execute figaro:heroku
/home/mark/.rvm/gems/ruby-1.9.3-p327@global/gems/bundler-1.3.0/lib/bundler/definition.rb:361:in validate_ruby!': Your Ruby version is 1.9.2, but your Gemfile specified 1.9.3 (Bundler::RubyVersionMismatch) from /home/mark/.rvm/gems/ruby-1.9.3-p327@global/gems/bundler-1.3.0/lib/bundler.rb:116:insetup'
from /home/mark/.rvm/gems/ruby-1.9.3-p327@global/gems/bundler-1.3.0/lib/bundler/setup.rb:17:in <top (required)>' from <internal:lib/rubygems/custom_require>:29:inrequire'
from internal:lib/rubygems/custom_require:29:in require' /home/mark/.rvm/gems/ruby-1.9.3-p327@global/gems/bundler-1.3.0/lib/bundler/definition.rb:361:invalidate_ruby!': Your Ruby version is 1.9.2, but your Gemfile specified 1.9.3 (Bundler::RubyVersionMismatch)
from /home/mark/.rvm/gems/ruby-1.9.3-p327@global/gems/bundler-1.3.0/lib/bundler.rb:116:in setup' from /home/mark/.rvm/gems/ruby-1.9.3-p327@global/gems/bundler-1.3.0/lib/bundler/setup.rb:17:in<top (required)>'
from internal:lib/rubygems/custom_require:29:in require' from <internal:lib/rubygems/custom_require>:29:inrequire'

Here's my setup:

$ gem env
RubyGems Environment:

• RUBYGEMS VERSION: 1.8.24
• RUBY VERSION: 1.9.3 (2012-11-10 patchlevel 327) [i686-linux]
• INSTALLATION DIRECTORY: /home/mark/.rvm/gems/ruby-1.9.3-p327@global
• RUBY EXECUTABLE: /home/mark/.rvm/rubies/ruby-1.9.3-p327/bin/ruby
• EXECUTABLE DIRECTORY: /home/mark/.rvm/gems/ruby-1.9.3-p327@global/bin
• RUBYGEMS PLATFORMS:
  • ruby
  • x86-linux
• GEM PATHS:
  • /home/mark/.rvm/gems/ruby-1.9.3-p327@global
• GEM CONFIGURATION:
  • :update_sources => true
  • :verbose => true
  • :benchmark => false
  • :backtrace => false
  • :bulk_threshold => 1000
  • "gem" => "--conservative"
  • "rdoc" => "--line-numbers"
• REMOTE SOURCES:
  • http://rubygems.org/

$ rvm list gemsets
rvm gemsets
ruby-1.9.2-p320 [ i386 ]
ruby-1.9.2-p320@global [ i386 ]
ruby-1.9.3-p327 [ i386 ]
=> ruby-1.9.3-p327@global [ i386 ]

$ head -n 3 Gemfile
source 'https://rubygems.org'
ruby '1.9.3'
gem 'bundler', ' = 1.3.0'

$ bundle exec bundle -v
Bundler version 1.3.0

$ bundle exec rails -v
Rails 3.2.12

$ cat Gemfile.lock | grep figaro
figaro (0.6.1)
figaro

$ cat /proc/version
Linux version 2.6.32-5-686 (Debian 2.6.32-48squeeze1) ([email protected]) (gcc version 4.3.5 (Debian 4.3.5-4) ) #1 SMP Mon Feb 25 01:04:36 UTC 2013

Figaro is great. However, how do you guys handle hard coded configuration values that are not sensitive and should be stored under source revision control?

This will work

HELLO: world
development:
  HELLO: developers
  GOODBYE: haters
production:
  HELLO: users

This won't

HELLO: world
development:
  HELLO: developers
production:
  HELLO: users
development:
  GOODBYE: haters

The second development block will overwrite the previous one. Depending on intended behavior, augment the docs or fix the bug? (Sorry to be terse... just spent a while fighting this!)

Figaro should support Rails 4.0.

I don't think there are any breaking changes in Rails 4.0 which are uncompatible with the gem.

Hi,

I have this config:

NAME:         "ØVERBYE"
ENGLISH_NAME: "OEVERBYE"

Ø is a Norwegian character.

The problem is that it will be escaped when accessing ENV['NAME']. So firing up my console gives:

1.9.3 (main):0 > ENV['NAME']
=> "\xC3\x98VERBYE"
1.9.3 (main):0 > ENV['NAME'].encoding
=> #<Encoding:ASCII-8BIT>

While the ENGLISH_NAME-variable will be correct and UTF-8 encoded:

1.9.3 (main):0 > ENV['ENGLISH_NAME']
=> "OEVERBYE"
1.9.3 (main):0 > ENV['ENGLISH_NAME'].encoding
=> #<Encoding:UTF-8>

Any thoughts on why this is happening?

On versions prior 0.6.X I used to have the following on my application.yml for development environment:

AGS_DB_DATABASE: 
AGS_DB_USERNAME: 
AGS_DB_PASSWORD: 
AGS_DB_HOST: 
AGS_DB_PORT:
AGS_DB_SOCKET: 

Since the update to 0.6.1 when trying to start the server with this configurations on dev I get:

/home/eticus/.rvm/gems/ruby-1.9.3-p327/gems/figaro-0.6.1/lib/figaro/env.rb:8:in `block in method_missing': undefined method `ags_db_database' for #<Figaro::Env:0xa5f5cd0> (NoMethodError)
    from /home/eticus/.rvm/gems/ruby-1.9.3-p327/gems/figaro-0.6.1/lib/figaro/env.rb:8:in `fetch'
    from /home/eticus/.rvm/gems/ruby-1.9.3-p327/gems/figaro-0.6.1/lib/figaro/env.rb:8:in `method_missing'
    from (erb):22:in `<main>'
    from /home/eticus/.rvm/rubies/ruby-1.9.3-p327/lib/ruby/1.9.1/erb.rb:838:in `eval'
    from /home/eticus/.rvm/rubies/ruby-1.9.3-p327/lib/ruby/1.9.1/erb.rb:838:in `result'
    from /home/eticus/.rvm/gems/ruby-1.9.3-p327/gems/railties-3.2.11/lib/rails/application/configuration.rb:115:in `database_configuration'
    from /home/eticus/.rvm/gems/ruby-1.9.3-p327/gems/activerecord-3.2.11/lib/active_record/railtie.rb:78:in `block (2 levels) in <class:Railtie>'
    from /home/eticus/.rvm/gems/ruby-1.9.3-p327/gems/activesupport-3.2.11/lib/active_support/lazy_load_hooks.rb:36:in `instance_eval'
    from /home/eticus/.rvm/gems/ruby-1.9.3-p327/gems/activesupport-3.2.11/lib/active_support/lazy_load_hooks.rb:36:in `execute_hook'
    from /home/eticus/.rvm/gems/ruby-1.9.3-p327/gems/activesupport-3.2.11/lib/active_support/lazy_load_hooks.rb:26:in `block in on_load'
    from /home/eticus/.rvm/gems/ruby-1.9.3-p327/gems/activesupport-3.2.11/lib/active_support/lazy_load_hooks.rb:25:in `each'
    from /home/eticus/.rvm/gems/ruby-1.9.3-p327/gems/activesupport-3.2.11/lib/active_support/lazy_load_hooks.rb:25:in `on_load'
    from /home/eticus/.rvm/gems/ruby-1.9.3-p327/gems/activerecord-3.2.11/lib/active_record/railtie.rb:74:in `block in <class:Railtie>'
    from /home/eticus/.rvm/gems/ruby-1.9.3-p327/gems/railties-3.2.11/lib/rails/initializable.rb:30:in `instance_exec'
    from /home/eticus/.rvm/gems/ruby-1.9.3-p327/gems/railties-3.2.11/lib/rails/initializable.rb:30:in `run'
    from /home/eticus/.rvm/gems/ruby-1.9.3-p327/gems/railties-3.2.11/lib/rails/initializable.rb:55:in `block in run_initializers'
    from /home/eticus/.rvm/gems/ruby-1.9.3-p327/gems/railties-3.2.11/lib/rails/initializable.rb:54:in `each'
    from /home/eticus/.rvm/gems/ruby-1.9.3-p327/gems/railties-3.2.11/lib/rails/initializable.rb:54:in `run_initializers'
    from /home/eticus/.rvm/gems/ruby-1.9.3-p327/gems/railties-3.2.11/lib/rails/application.rb:136:in `initialize!'
    from /home/eticus/.rvm/gems/ruby-1.9.3-p327/gems/railties-3.2.11/lib/rails/railtie/configurable.rb:30:in `method_missing'
    from /home/eticus/workspaces/ix-workspace/app-generator-sever/config/environment.rb:5:in `<top (required)>'
    from /home/eticus/.rvm/gems/ruby-1.9.3-p327/gems/activesupport-3.2.11/lib/active_support/dependencies.rb:251:in `require'
    from /home/eticus/.rvm/gems/ruby-1.9.3-p327/gems/activesupport-3.2.11/lib/active_support/dependencies.rb:251:in `block in require'
    from /home/eticus/.rvm/gems/ruby-1.9.3-p327/gems/activesupport-3.2.11/lib/active_support/dependencies.rb:236:in `load_dependency'
    from /home/eticus/.rvm/gems/ruby-1.9.3-p327/gems/activesupport-3.2.11/lib/active_support/dependencies.rb:251:in `require'
    from /home/eticus/workspaces/ix-workspace/app-generator-sever/config.ru:3:in `block in <main>'
    from /home/eticus/.rvm/gems/ruby-1.9.3-p327/gems/rack-1.4.5/lib/rack/builder.rb:51:in `instance_eval'
    from /home/eticus/.rvm/gems/ruby-1.9.3-p327/gems/rack-1.4.5/lib/rack/builder.rb:51:in `initialize'
    from /home/eticus/workspaces/ix-workspace/app-generator-sever/config.ru:in `new'
    from /home/eticus/workspaces/ix-workspace/app-generator-sever/config.ru:in `<main>'
    from /home/eticus/.rvm/gems/ruby-1.9.3-p327/gems/rack-1.4.5/lib/rack/builder.rb:40:in `eval'
    from /home/eticus/.rvm/gems/ruby-1.9.3-p327/gems/rack-1.4.5/lib/rack/builder.rb:40:in `parse_file'
    from /home/eticus/.rvm/gems/ruby-1.9.3-p327/gems/rack-1.4.5/lib/rack/server.rb:200:in `app'
    from /home/eticus/.rvm/gems/ruby-1.9.3-p327/gems/railties-3.2.11/lib/rails/commands/server.rb:46:in `app'
    from /home/eticus/.rvm/gems/ruby-1.9.3-p327/gems/rack-1.4.5/lib/rack/server.rb:304:in `wrapped_app'
    from /home/eticus/.rvm/gems/ruby-1.9.3-p327/gems/rack-1.4.5/lib/rack/server.rb:254:in `start'
    from /home/eticus/.rvm/gems/ruby-1.9.3-p327/gems/railties-3.2.11/lib/rails/commands/server.rb:70:in `start'
    from /home/eticus/.rvm/gems/ruby-1.9.3-p327/gems/railties-3.2.11/lib/rails/commands.rb:55:in `block in <top (required)>'
    from /home/eticus/.rvm/gems/ruby-1.9.3-p327/gems/railties-3.2.11/lib/rails/commands.rb:50:in `tap'
    from /home/eticus/.rvm/gems/ruby-1.9.3-p327/gems/railties-3.2.11/lib/rails/commands.rb:50:in `<top (required)>'
    from script/rails:6:in `require'
    from script/rails:6:in `<main>'

The workaround for now is to do the following:

AGS_DB_DATABASE: ""
AGS_DB_USERNAME: ""
AGS_DB_PASSWORD: ""
AGS_DB_HOST: ""
AGS_DB_PORT: ""
AGS_DB_SOCKET: ""

Is this an expected functionality for the 0.6.X if it is just close the issue.
Thanks
Enrique

I use Figaro since yesterday and I find it great.
However I have the impression that there is no proper way of using optional configuration variables.

When a configuration variable is not defined, Figaro.env.my_optional_variable raises. We can still use ENV["MY_OPTIONAL_VARIABLE"] or Figaro.env.respond_to?(:my_optional_variable), but the first solution does not allow stubbing, and the second solution does not allow to simulate (in test) the case where the optional variable has not been set.

I see 4 solutions to this problem. Depending on the preferred solution, I may try to implement it, and make a pull request.

First solution
Let Figaro.env.my_optional_variable return nil when the variable is not defined. This is consistent with ENV["MY_OPTIONAL_VARIABLE"] but I wonder what Figaro.env.respond_to?(:my_optional_variable) should return. Always true? Anyway, this could be considered as a breaking change.

Second solution
Implement a method Figaro::Env#set?(method) that returns true if the variable has been set and is not blank:

# Returns true if configuration var has been set to a non blank value
def set?(method)
  respond_to?(method) && send(method).present?
end

Developper should use this method to test if an optional configuration variable has been set. Contrary to respond_to?, we can simulate an undefined configuration variable by stubbing Env#my_optional_variable to return nil (or an empty string).
Example with Mocha:

Figaro::Env.any_instance.stubs(my_optional_variable: nil)

Note: I stub Figaro::Env.any_instance instead of Figaro.env because the later doesn't seem sufficient in some cases. It may be related to #57.

Third solution
Modify Env#method_missing so that calling Figaro.env.my_optional_variable? is equivalent to calling Figaro.env.set?(:my_optional_variable) as described in the second solution.

Fourth solution
Let Figaro use a file with default values for configuration. All optional configuration variables would be defined here with an empty string, so we can test if a configuration variable is missing with Figaro.env.my_optional_variable.blank?.
This is a bigger work, but would also respond to #50 and #49.

It seems that environment variables defined within the application.yml file override ones explicitly passed into rails commands. For example, if my application.yml has TEST_VAR: 3 and I run TEST_VAR=100 rails server from the command line, trying ENV['TEST_VAR'] within my Rails app returns 3 instead of 100 (as I would expect).

I think this functionality is important because, for example, our team has several developers that each need to share localhost on different domains (for testing on IE/mobile). The "main" domain for the site comes from a single environment variable that we'd like to easily change for each person.

I propose rake figaro:display which would display all the ENV fields alphabetically, in human-readable fashion:

      KEY_1 = some_value
LONG_KEY_11 = other_value_which_is_long
  OTHER_KEY = the_last_value

I can see only one usecase for it: Running in CI environment to provide an additional information what variables were used.

I do it already in my project, I can submit a pull request. However I'm not sure if it's that usable for other people and if it's advocated to add yet another feature to gem which beauty is in its simplicity. During last few months, such output was rarely useful.

Figaro works well with Rails but it would be great if it could be dropped into any ol' Rack app. Some considerations:

1. Can't use the railtie, so how is the configuration loaded?
2. How does Figaro determine the application's root directory?
3. Is config/application.yml still a good convention?

Im trying to use the

rake figaro:heroku[my-lovely-staging-app]

task to set my config vars in Staging environment on Heroku, but it is my Development vars that gets set.

How do i tell figaro which environment I want the vars set for?

Hello,

I am working on a project with Rails 4 and Capistrano 3 and I am using Figaro to handle the configuration variables.

When I try to access Figaro variables from a Capistrano task I have found this caveat:

To use Figaro.env I have to load Rails first (which capistrano 3 is not doing by default). I do so like this:

#config/deploy/staging.rb
ENV["RAILS_ENV"] = "staging" # This is necessary or Rails.env will be "development" and Figaro will use development vars instead of staging.
require File.expand_path('../environment',  __FILE__) 

Is there a way to make figaro do its thing (make variables for a certain environment accessible as ENV["blah"]) without loading Rails?

Isn't it possible to expose the functionality in a public method and then if the gem is used by Rails, call this method in the hook as you do now?

In addition to the default application.yml naming, it might be useful to accept additional file naming such as:

• config.yml
• env.yml
• configuration.yml

Maybe I'm missing something completely obvious, but is it possible pull ENV variables from Heroku config and insert them with figaro locally in to the application.yml file?

Use case is that I have both a desktop and laptop computer and so I switch development between the two and would like to be able to use the same ENV variables on both machines.

First of all, thanks for this awesome tool - I can't imagine trying to maintain my config across many environments without it.

However, I did notice recently that my config variables were not pushing correctly according to their environments. I am using the syntax described here:

# Facebook app ID and secret
FACEBOOK_APP_ID: <development-app-id>
production:
  FACEBOOK_APP_ID: <production-app-id>

FACEBOOK_SECRET: <development-app-secret>
production:
  FACEBOOK_SECRET: <production-app-secret>

After running rake figaro:heroku[my-app-name], then checking the config with heroku config -a my-app-name, I see the following env variables set:

FACEBOOK_APP_ID: <development-app-id>
FACEBOOK_SECRET: <production-app-secret>
RACK_ENV: production
RAILS_ENV: production

Although the syntax is the same for each, it is taking my development app id and my production app secret. I looked at #35 #28 and #7 and I have both RAILS_ENV and RACK_ENV set to production on Heroku. I'm not sure if I am missing something or if I've uncovered a bug here. Any ideas?

Seems figaro requires the heroku gem, which has now been deprecated. Not a big deal, you can still use the old gem, but maybe a good idea to update

$ rake figaro:heroku[leanstartupcircle-staging]
/Users/tristankromer/.rvm/gems/ruby-1.9.2-p290@global/gems/bundler-1.0.21/lib/bundler/rubygems_integration.rb:143:in `block in replace_gem': heroku is not part of the bundle. Add it to Gemfile. (Gem::LoadError)
from /Users/tristankromer/.rvm/gems/ruby-1.9.2-p290/bin/heroku:18:in `<main>'
/Users/tristankromer/.rvm/gems/ruby-1.9.2-p290@global/gems/bundler-1.0.21/lib/bundler/rubygems_integration.rb:143:in `block in replace_gem': heroku is not part of the bundle. Add it to Gemfile. (Gem::LoadError)
from /Users/tristankromer/.rvm/gems/ruby-1.9.2-p290/bin/heroku:18:in `<main>'

When open sourcing a Rails app, Travis is a great (free) tool for testing the app. However, when using Figaro, the configuration sometimes needed for running the test suite (Pusher credentials, Stripe credentials, etc.) aren't included in the Travis build environment.

It would be nice to have a rake figaro:travis Rake task to add the env configuration to .travis.yml. Currently, Travis only supports env configurations in the clear but there's a pending pull request that would allow you to encrypt them.

This would swing the door wide open to distributed, private config, public app testing.

I have a rather large app and I'd love the ability to split my configs into multiple files.

So if config/application.yml doesn't exist, Figaro would look for a figaro directory and I could have something like this:

config
 |-- figaro
      |-- application.yml
      |-- twitter.yml
      |-- sendgrid.yml
      ...

Which could then be accessed via:

Figaro.env.twitter.api_key and would map to ENV['FIGARO_TWITTER_API_KEY']

Anything under application.yml would be mapped to the Rails (or some default for non-Rails projects) application name:

Figaro.env.my_app.base_url

What do you all think? @laserlemon maybe for the v1.0.0 release? Are you planning on publishing a branch for it? I'd be glad to help out.

https://github.com/mojombo/toml