The default value for RAILS_ENV is set to “development” in initializer.rb, which is loaded right after boot.rb has determined the boot strategy.
I created a “config/preinitializer.rb” which was supposed to provide another default value for RAILS_ENV (“staging” or “production”, depending on the host), but it doesn’t work in all cases. Specifically, commands executed by “console”, “dbconsole”, “runner” and “server” scripts all set RAILS_ENV to “development” as default and ruins my preinitializer idea since these scripts happen before the actual initialization phase.
The workaround right now is to hardcode the RAILS_ENV value in preinitializer.rb without respecting the ENV[“RAILS_ENV”] variable, but that disables the possiblity that I actually start the app in some custom environment other than what I wanted to hardcode for this host.
What I would like to do is remove the “development” default from script/console, script/runner and script/server (removing it from “dbconsole” is not possible since it doesn’t load the environment) and unless anyone can find an objection to this, I will be posting a patch.
Also, the default generated test_helper hardcodes RAILS_ENV to test
(or used to, I didn't check master). I guess that's the best place,
but thought I'd mention it in case it is relevant to your patch.
It does seem like a bad idea to have it hardcoded to development in
initializer.rb.
I've never run into your problem, though. quick fix: set RAILS_ENV to
the appropriate value in your system wide bashrc on staging and
production machines.
What I would like to do is remove the "development" default from
script/console, script/runner and script/server (removing it from
"dbconsole" is not possible since it doesn't load the environment) and
unless anyone can find an objection to this, I will be posting a patch.
This sounds like a good change to me.
+1
Also, the default generated test_helper hardcodes RAILS_ENV to test
(or used to, I didn't check master). I guess that's the best place,
but thought I'd mention it in case it is relevant to your patch.
I dunno about changing this one, accidentally running your tests
against another environment can be pretty catastrophic.
I don’t think Chad suggested it needs to be changed; he just pointed out the only other place where RAILS_ENV needs to be hardcoded (apart from initializer.rb)
It does seem like a bad idea to have it hardcoded to development in
initializer.rb.
Well, somewhere it does have to default to “development”.
I’ve never run into your problem, though. quick fix: set RAILS_ENV to
the appropriate value in your system wide bashrc on staging and
production machines.
Yeah I got that a lot. Problem is, there are other apps on the same machine running in different environments. I don’t want a system-wide setting, I want it per-app so that’s why I’m using a preinitializer.
Wouldn't it make more sense to set it in the vhost (if you're using
Passenger) or with your Mongrel config (or the like). I write app's
that live on many environments (qa, stage, prod, admin, ci, dev, test,
etc.) and have never once had an issue with RAILS_ENV.
I’m not having issues with RAILS_ENV. I’d just like if you didn’t specify it, that it defaults to some pre-configured environment other than “development”.
The problem with setting environment everywhere explicitly means you have to check your Passenger/Mongrel config, god recipes, delayed_job workers, scripts than run rake tasks, cron jobs, scripts that run migrations … and let’s not forget you have to specify the environment every time you open script/console. It’s getting a little tedious, especially because I want to re-use configurations I already have for a different app and not care whether that app runs in a different environment than this one.