This project is archived and is in readonly mode.
E.g. "rails server -e test" doesn't work, "RAILS_ENV=test rails server" does
-
Henrik Nyh
Okay, so this is due to Rails.env caching its results in @_env.
When starting a server, config/application.rb:6 in my freshly generated app calls Rails.env:
Bundler.require :default, Rails.envAt this stage it's "development", so that is cached into @_env. When the server later changes RAILS_ENV and outputs Rails.env, it's too late.
I know too little about Rails initialization to know what would be the proper way to fix this. I'll keep digging for a little while longer.
-
Kieran P
So it looks like a more serious issue as well:
Bundler.require will always load the wrong environment unless RAILS_ENV is used
-
Simo Niemelä
- Tag changed from initialization, rails3, server to initialization, patch, rails3, server
I created a patch for this issue.
-
Henrik Nyh
Nice!
Haven't tried the patch yet, but just reading the diff, I'm thinking
it may reactivate the bug (#3874) with double help banners. Basically,
calling "options" with the -h option given will show the help banner,
then bail before the options can be stored, so calling "options" again
will run the banner code again, showing it multiple times.So if this triggers the issue, doing "@options && options[:environment]" would fix it, but I suppose it would be better
to try to fix #3874 "rails server --help" shows help twice and without "server" in usage in a way that you don't have to know to do that.
I'll see if I can revisit it sometime soon. -
Prem Sichanugrist (sikachu)
- Milestone cleared.
- State changed from new to verified
- Assigned user set to José Valim
Patch from Simo Niemelä applied cleanly on
master, and all the tests are passed. And the bug is really because that premature calling ofRails.env.. nice catch!I can verify that 'double help banner bug' in #3874 "rails server --help" shows help twice and without "server" in usage does not happen after apply this patch:
Sikachus-Notebook:test_edge sikachu$ rails server -h Usage: rails server [options] -p, --port=port Runs Rails on the specified port. Default: -b, --binding=ip Binds Rails to the specified ip. Default: -c, --config=file Use custom rackup configuration file -d, --daemon Make server run as a Daemon. -u, --debugger Enable ruby-debugging for the server. -e, --environment=name Specifies the environment to run this server under (test/development/production). Default: -h, --help Show this help message.However, you can see that there're missing default values. In
Rack::Server, they actually hardcoded the default values. I'll provide the patch with that default values set.Will assign to José to get it applied into
master. Note that there're some whitespaces warning. -
José Valim
I'm afraid that the current patch will make RAILS_ENV break, because it's doing ENV["RAILS_ENV"] = options[:environment] and not ENV["RAILS_ENV"] ||= options[:environment].
-
Simo Niemelä
Yeah, you are right about that. I created another patch which has that fix (
ENV["RAILS_ENV"] ||= options[:environment]instead ofENV["RAILS_ENV"] = options[:environment]). -
Repository
(from [cafe882d12d767f510d6b8ad283f49a1c02e82ad]) Fix server environment [#3877 E.g. "rails server -e test" doesn't work, "RAILS_ENV=test rails server" does status:resolved]
Signed-off-by: José Valim jose.valim@gmail.com
http://github.com/rails/rails/commit/cafe882d12d767f510d6b8ad283f49... -
Prem Sichanugrist (sikachu)
- State changed from verified to resolved
