We're doing an upgrade to Ruby on Rails 3 (like half the world right now), and I've been diligently replacing usages of RAILS_ENV, for example
RAILS_ENV == 'wibble'
# becomes
Rails.env.wibble?
But I'm not as certain of what to do with:
ENV["RAILS_ENV"] ||= 'production'
We've got it at the top of a whole bunch of Rake tasks and daemons, and the idea is that you can pass RAILS_ENV on the command-line, but it defaults to 'production' if it's not passed.
I'm not sure of the new Rails3-appropriate way of doing this. So for now my rails:upgrade:check is complaining mightily of this intrusion of Rails2-ishness...
I don't know if:
::Rails.env ||= 'production'
will work.
Does Rails.env exist in a daemon?
Does it automagickally get pre-populated with the value of RAILS_ENV passed on the command-line or do we need a new way of invoking the daemons?
What is the correct mantra for this?
Update:
Looking into the source-code for Rails.env,
def env
@_env ||= ActiveSupport::StringInquirer.new(RAILS_ENV)
end
we can deduce a number of things.
Firstly, it looks like RAILS_ENV does actually still exist - which means it can be set and Rails.env will find it...
If Rails is valid in the context of a daemon, then nothing more needs to be done. If not - then I could just not care much and use the old RAILS_ENV as before.