Figaro not loading config in application.rb for Rails v4.2

[fny]

Just updated to Rails v4.2.0, and noticed that Figaro is no longer setting the environment in application.rb as it used to in Rails v4.1:

module MyApp
  class Application < Rails::Application
     ENV['SET_BY_FIGARO'] # => nil
     Figaro.env.SET_BY_FIGARO # => nil
  end
end

Everything still works from an initializer though... although I do need access to the values sooner to use in the config files.

[laserlemon]

Would you be willing to contribute a failing test?

[fny]

I'll give it a go. I managed to fix it by adding Figaro.load to the top of the class Application... bit.

[moyboy5]

Hello. @laserlemon , I am having the same problem with rails 4.2, where none of my environment variables were getting set. I added Figaro.load to the top of my application class as well and it worked. No require 'figaro' needed like in some of the other troubleshooting threads I saw.

[laserlemon]

There's already a test that asserts that ENV is set immediately after the Rails application is defined, exactly as is described in the initial code example. This test is run against Rails 4.2. Until somebody can produce a failing test, I'm not able to reproduce the problem. @fny, any luck with a test?

[fny]

Would it be enough if I set up a sample rails application?

On Tue, Apr 21, 2015 at 10:24 PM, Steve Richert [email protected] wrote:

There's already a test https://github.com/laserlemon/figaro/blob/7d950c1c100f93142373ed9a1ef00868fa9d30a5/spec/rails_spec.rb#L40-L48 that asserts that ENV is set immediately after the Rails application is defined, exactly as is described in the initial code example. This test is run against Rails 4.2. Until somebody can produce a failing test, I'm not able to reproduce the problem. @fny https://github.com/fny, any luck with a test?

— Reply to this email directly or view it on GitHub https://github.com/laserlemon/figaro/issues/186#issuecomment-95000290.

[laserlemon]

It would be a start. The test suite actually generates a brand new Rails 4.2 app and then modifies it in different ways to test its behavior, so it'd still be best if you could write/commit a failing test.

[fny]

I'm actually not sure about where to put this in the tests, but it's simple to reproduce:

Here's the repo: https://github.com/fny/figaro_fail/commits/master

With a vanilla Rails 4.2 app (rails new figaro_fail) and a basic Figaro setup (say we've got a config key "hello: howdy"), the following breaks upon running the app: https://github.com/fny/figaro_fail/commit/6f738b47567dc23a5bacccad8a164ee39f468225

And it's easily fixed by adding this line: https://github.com/fny/figaro_fail/commit/97e2f116424131d1e5f7cf36651267885fef7813

[laserlemon]

Okay, thanks. I just did a little digging and here's what I came up with…

My test works because this is the code I test to ensure configuration is available immediately following application inheritance:

module Example
  class Application < Rails::Application
    config.foo = ENV["foo"]
  end
end

This works. I'll get to why.

On the other hand, this code will not work:

module Example
  class Application < Rails::Application
    puts ENV["foo"]
  end
end

The reason the first example works and the second doesn't is because the before_configuration hook (the earliest hook available) that Figaro ties into doesn't run until the new instance of the Example::Application is initialized. Initializing the singleton application instance happens when the instance method is called on the Example::Application class. It just so happens that the config class method delegates to instance.

So the fact that my example evaluates config before it evaluates ENV["foo"] avoids the issue by initializing the instance just in time. In your example, by the time you evaluate ENV["foo"], the instance has yet to be initialized.

Off the top of my head, I'm not sure how to get around this, outside of the Figaro.load workaround you've already come up with. Thoughts?

[fny]

So I'm thinking this is a regression in Rails, since this was working before Rails 4.2. The problem you stated is exactly correct, the before_configuration hook is actually never run until config is called for the first time, which lazily loads a config instance. So, this actually works too:

module Example
  class Application < Rails::Application
    config
    puts ENV["foo"]
  end
end

I'd say the smartest thing to do would be to add a note in the documentation and submit an issue about the regression to Rails.

[laserlemon]

Issue submitted. :point_up:

[fny]

That's one hell of an issue submission. :clap:

Thanks!

[laserlemon]

:+1:

[rodrei]

Just wanted to confirm that I had the same issue. I fixed it by adding an initializer with Figaro.load.

One problem with this approach is that values are not updated after modifying config/application.yml. In order for the updates to be recognized I had to stop spring by running spring stop.

[jtoy]

omg, just wasted an hour of my life debugging this. wtf do we need to run spring stop for our variables to update.

[bobzhen]

bin/spring stop

this is awesome

[patwalls]

@bobzhen That command fixed it for me. I'm just in my dev environment right now but would I have to run that in production as well?

[brendon]

This was fixed with https://github.com/rails/rails/pull/26216 thank goodness!

I found that

production:
  secret_key_base: <%= ENV["SECRET_KEY_BASE"] %>

failed because the ENV wasn't set in time.