#1750 session_store initializer causes rake:gems tasks to break - Ruby on Rails

Type	To find
responsible:me	tickets assigned to you
tagged:"@high"	tickets tagged @high
milestone:next	tickets in the upcoming milestone
state:invalid	tickets with the state invalid
created:"last week"	tickets created last week
sort:number, importance, updated	tickets sorted by #, importance or updated
Combine keywords for powerful searching.
Use advanced searching »

This project is archived and is in readonly mode.

#1750 ✓resolved

session_store initializer causes rake:gems tasks to break

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

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.

Comments and changes to this ticket

Michael Klett February 3rd, 2009 @ 07:36 PM

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.

You flagged this item as spam.
Adam McCrea February 6th, 2009 @ 03:14 PM
- 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
- always_run_initializers_with_rake_gems.diff 2.6 KB
You flagged this item as spam.
Adam McCrea February 6th, 2009 @ 03:17 PM
Bah! My diff contained some unnecessary junk. Here is the corrected patch.
- always_run_initializers_with_rake_gems.diff 1.6 KB
DHH February 7th, 2009 @ 01:26 PM
- Assigned user set to “josh”
- Milestone cleared.
josh February 7th, 2009 @ 05:09 PM
- Assigned user changed from “josh” to “Rick”
You flagged this item as spam.
dstrelau February 12th, 2009 @ 09:24 PM
Just a +1 to say that I'm running into this too.
You flagged this item as spam.
iain February 13th, 2009 @ 02:41 PM
+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)
```
Matt Jones February 18th, 2009 @ 12:56 AM
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...
- fix-initializer-with-missing-gems.patch 1.9 KB
You flagged this item as spam.
austinfromboston February 20th, 2009 @ 06:32 PM
+1 matt jones' patch works -- we vendored rails and apply the patch in our template and all goes swimmingly.
josh February 20th, 2009 @ 08:14 PM
- Assigned user changed from “Rick” to “josh”
- State changed from “new” to “open”
Repository February 20th, 2009 @ 08:20 PM
- 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...
You flagged this item as spam.
Thijs February 25th, 2009 @ 08:43 PM
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?
josh February 25th, 2009 @ 09:44 PM
@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