Lighthouse has a new layout. Prefer the old one? Return to the old layout, and switch back any time from the link at the top of each page.

This project is archived and is in readonly mode.

E.g. "rails server -e test" doesn't work, "RAILS_ENV=test rails server" does

#3877

Looks like "railties/lib/rails/commands/server.rb" successfully sets RAILS_ENV to "test" when doing "rails server -e test", but Rails.env is still set to development:

henrik@Nyx ~/Sites/rails3test$ rails server -e test
=> Booting WEBrick
=> Rails 3.0.0.beta application starting in development on http://0.0.0.0:3000

The "starting in development" string uses Rails.env. I also made a controller raise Rails.env and that was "development", too. So it's not just server.rb showing the wrong value.

My guess is that server.rb changes ENV['RAILS_ENV'] too late, after it's already been read for Rails.env.

It works as expected with "RAILS_ENV=test rails server":

henrik@Nyx ~/Sites/rails3test$ RAILS_ENV=test rails server
=> Booting WEBrick
=> Rails 3.0.0.beta application starting in test on http://0.0.0.0:3000

All this is on OS X.

I'll see if I can patch it, but I don't have a lot of time to spare right now.

Reported by Henrik Nyh · February 6th, 2010 @ 12:14 PM

State: resolved
Milestone: 3.0.2
Assigned to: José Valim José Valim
Importance: Medium

Activity

  1. Henrik Nyh
    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.env
    

    At 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.

    February 6th, 2010 @ 12:26 PM

  2. Kieran P
    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

    February 6th, 2010 @ 07:52 PM

  3. Simo Niemelä
    Simo Niemelä
    • Tag changed from initialization, rails3, server to initialization, patch, rails3, server

    I created a patch for this issue.

    February 8th, 2010 @ 08:44 PM

  4. Henrik Nyh
    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.

    February 8th, 2010 @ 08:54 PM

  5. Prem Sichanugrist (sikachu)
    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 of Rails.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.

    February 9th, 2010 @ 02:00 PM

  6. José Valim
    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].

    February 9th, 2010 @ 02:04 PM

  7. Simo Niemelä
    Simo Niemelä

    Yeah, you are right about that. I created another patch which has that fix (ENV["RAILS_ENV"] ||= options[:environment] instead of ENV["RAILS_ENV"] = options[:environment]).

    February 9th, 2010 @ 09:39 PM

  8. Repository
  9. Prem Sichanugrist (sikachu)
    Prem Sichanugrist (sikachu)
    • State changed from verified to resolved

    February 10th, 2010 @ 07:21 AM

  10. Jeremy Kemper
    Jeremy Kemper
    • Milestone set to 3.0.2
    • Importance changed from to Medium

    October 15th, 2010 @ 11:01 PM