This project is archived and is in readonly mode.

#3877 ✓resolved
Henrik Nyh

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

Reported by Henrik Nyh | February 6th, 2010 @ 12:14 PM | in 3.0.2

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.

Comments and changes to this ticket

  • Henrik Nyh

    Henrik Nyh February 6th, 2010 @ 12:26 PM

    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.

  • Kieran P

    Kieran P February 6th, 2010 @ 07:52 PM

    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ä

    Simo Niemelä February 8th, 2010 @ 08:44 PM

    • Tag changed from “initialization, rails3, server” to “initialization, patch, rails3, server”

    I created a patch for this issue.

  • Henrik Nyh

    Henrik Nyh February 8th, 2010 @ 08:54 PM

    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 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)

    Prem Sichanugrist (sikachu) February 9th, 2010 @ 02:00 PM

    • 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 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

    José Valim February 9th, 2010 @ 02:04 PM

    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ä

    Simo Niemelä February 9th, 2010 @ 09:39 PM

    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]).

  • Repository

    Repository February 10th, 2010 @ 07:17 AM

  • Prem Sichanugrist (sikachu)

    Prem Sichanugrist (sikachu) February 10th, 2010 @ 07:21 AM

    • State changed from “verified” to “resolved”
  • Jeremy Kemper

    Jeremy Kemper October 15th, 2010 @ 11:01 PM

    • Milestone set to “3.0.2”
    • Importance changed from “” to “Medium”

Create your profile

Help contribute to this project by taking a few moments to create your personal profile. Create your profile »

<h2 style="font-size: 14px">Tickets have moved to Github</h2>

The new ticket tracker is available at <a href="https://github.com/rails/rails/issues">https://github.com/rails/rails/issues</a>

People watching this ticket

Attachments

Tags

Referenced by

Pages