According to the docs, #Rails.env
wraps RAILS_ENV
:
# File vendor/rails/railties/lib/initializer.rb, line 55
def env
@_env ||= ActiveSupport::StringInquirer.new(RAILS_ENV)
end
But, look at specifically how it's wrapped, using ActiveSupport::StringInquirer
:
Wrapping a string in this class gives you a prettier way to test for equality. The value returned by Rails.env is wrapped in a StringInquirer object so instead of calling this:
Rails.env == "production"
you can call this:
Rails.env.production?
So they aren't exactly equivalent, but they're fairly close. I haven't used Rails much yet, but I'd say #Rails.env
is certainly the more visually attractive option due to using StringInquirer
.
ENV['RAILS_ENV']
is now deprecated.
You should use Rails.env
which is clearly much nicer.
Before Rails 2.x the preferred way to get the current environment was using the RAILS_ENV
constant. Likewise, you can use RAILS_DEFAULT_LOGGER
to get the current logger or RAILS_ROOT
to get the path to the root folder.
Starting from Rails 2.x, Rails introduced the Rails
module with some special methods:
This isn't just a cosmetic change. The Rails module offers capabilities not available using the standard constants such as StringInquirer
support.
There are also some slight differences. Rails.root
doesn't return a simple String
buth a Path
instance.
Anyway, the preferred way is using the Rails
module. Constants are deprecated in Rails 3 and will be removed in a future release, perhaps Rails 3.1.
Strange behaviour while debugging my app: require "active_support/notifications" (rdb:1) p ENV['RAILS_ENV'] "test" (rdb:1) p Rails.env "development"
I would say that you should stick to one or another (and preferably Rails.env)
Update: in Rails 3.0.9: env method defined in railties/lib/rails.rb
If you love us? You can donate to us via Paypal or buy me a coffee so we can maintain and grow! Thank you!
Donate Us With