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.

session_store initializer causes rake:gems tasks to break

#1750

I am on edge Rails. I have a gem configured in my environment.rb, but I do not have it installed.

When I run rake:gems, I get the following output:

rake aborted!
A session_key is required to write a cookie containing the session data. Use config.action_controller.session = { :session_key => "_myapp_session", :secret => "some secret phrase" } in config/environment.rb

The problem began when the session_store config was moved from the environment.rb to a separate initializer file commit.

Initializers are not loaded unless gem dependencies are loaded, so the session_store initializer doesn't get to do its business.

I'm not sure of the appropriate solution -- either load initializers regardless of gem dependencies, or fake it when rake:gems is being run. The latter could be accomplished in the check_gem_dependencies method:

  def check_gem_dependencies
    unloaded_gems = @configuration.gems.reject { |g| g.loaded? }
    if unloaded_gems.size > 0
      @gems_dependencies_loaded = false
      # don't print if the gems rake tasks are being run
      unless $rails_gem_installer
        abort <<-end_error

By moving @gems_dependencies_loaded = false underneath unless $rails_gem_installer, it would ignore non-loaded gems if rake:gems is being run.

Reported by Adam McCrea · January 13th, 2009 @ 05:42 PM

State: resolved
Milestone: none
Assigned to: josh josh
Importance: none

Activity

  1. Michael Klett
    Michael Klett
    • Tag set to cookiestore, gems

    I'm running in to this too. Would it be good enough to abort the CookieStore initialization if

    @@@ruby $rails_rake_task = true

    
    
    I see this done elsewhere in the intializer.rb code, but I'm not sure where the CookieStore gets initialized, or what other implications this would have.  I would think that you would not need access to the session for most rake tasks.
    

    February 3rd, 2009 @ 07:36 PM

  2. Adam McCrea
    Adam McCrea
    • Tag changed from cookiestore, gems to cookiestore, gems, patch

    Here is a patch to make it work, but I have no idea how to unit test it. To recreate the bug in an application:

    1. add a gem dependency for a gem that you do not have installed
    2. run rake:gems

    February 6th, 2009 @ 03:14 PM

  3. Adam McCrea
    Adam McCrea

    Bah! My diff contained some unnecessary junk. Here is the corrected patch.

    February 6th, 2009 @ 03:17 PM

  4. DHH
    DHH
    • Assigned user set to josh
    • Milestone cleared.

    February 7th, 2009 @ 01:26 PM

  5. josh
    josh
    • Assigned user changed from josh to Rick

    February 7th, 2009 @ 05:09 PM

  6. dstrelau
    dstrelau

    Just a +1 to say that I'm running into this too.

    February 12th, 2009 @ 09:24 PM

  7. iain
    iain

    +1 for this one.


    Besides the point:

    This issue gets in the way of Rails Templates. Templates would be a good way to add a certain functionality to your project, which requires multiple steps, but by making a template, it should just work!

    @@@ruby

    install cucumber template

    gem 'cucumber' rake "gems:install", :sudo => true generate :cucumber

    
    
    (templates should be available to install.rb of plugins too, but that's another issue)
    

    February 13th, 2009 @ 02:41 PM

  8. Matt Jones
    Matt Jones

    As noted on other tickets: running initializers when gems aren't present is DOING IT WRONG. While it fixes this single case, it will make most situations fail dramatically.

    For instance, when using the Settings gem (app-wide settings, stored in the DB), one typically uses an intializer to set default values:

    
    # in config/initializers/default_settings.rb
    Settings.default[:foo] = "bar"
    

    Loading this initializer without the gem is bad, bad, bad. The real solution is going to require that config.gem (or equivalent) move out of environment.rb into something loaded earlier; it's not good that the gems: Rake tasks depend on the environment.

    I've attached a patch that breaks out of the initializer entirely if gems are missing in the gems rake tasks. This should solve both this bug and the problem where loading, for example, ApplicationController required missing gems.

    No idea how to write a "test" for this, but the behavior is pretty clear from the code...

    February 18th, 2009 @ 12:56 AM

  9. austinfromboston
    austinfromboston

    +1 matt jones' patch works -- we vendored rails and apply the patch in our template and all goes swimmingly.

    February 20th, 2009 @ 06:32 PM

  10. josh
    josh
    • Assigned user changed from Rick to josh
    • State changed from new to open

    February 20th, 2009 @ 08:14 PM

  11. Repository
    Repository
    • State changed from open to resolved

    (from [01c818e99f04f70462df68e6a217dfd280c37581]) break out of initializer early if gems aren't loaded [#1750 state:resolved]

    Signed-off-by: Joshua Peek josh@joshpeek.com http://github.com/rails/rails/co...

    February 20th, 2009 @ 08:20 PM

  12. Thijs
    Thijs

    This now seems to break if you have your session config defined in environment.rb the old way. Took me an hour :-). Would that be considered a bug? Maybe this should be included in the docs?

    February 25th, 2009 @ 08:43 PM

  13. josh
    josh

    @Thijs can you retest on edge rails. If its still a problem please open a new ticket. config.action_controller.session_options = should still work

    February 25th, 2009 @ 09:44 PM