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.

Rails.root returns nil before app initialization, silently breaking some gems

#4016

While updating thinking-sphinx gem to work with rails 3.0, I've noticed that it got wrong paths for its configuration files, like absolute "/config/..", "/db/..." instead of relative "#{Rails.root}/config".

Problem is, in rails 2.x gems were required after Rails.root is initialized. And default rails 3.0 application generator uses Bundler, and auto-requires all gems before application initialization. That problem could be easily solved with "gem 'problem-gem', :require => false" in Gemfile, and separate "require 'problem-gem'" in initializer, but it's annoyingly hard to track such a bug.

I'm pretty sure many other rails dependent gems check for defined?(Rails) but do not check for Rails.root.nil?, and use it blindly in paths calculation

there's a method in module Rails:

    def root
      application && application.config.root
    end

it seems to me that it shouldn't just silently return "nil" before application initialization, but rather throw some exception with a helpful message. What do you think?

And what is a new standard method for rails dependent gem initialization? Should it go in custom config/initializers/...rb, or put int config/application.rb itself?

I'll make a patch if this is a way to go.

Reported by codesnik · February 21st, 2010 @ 02:04 AM

State: wontfix
Milestone: none
Assigned to: nobody
Importance: none

Activity

  1. codesnik
    codesnik

    seems that #4009 Move Bundler.require below class Application; end addresses the same issue and has a patch. Still, raising exception could make sense

    February 21st, 2010 @ 02:11 AM

  2. José Valim
    José Valim
    • State changed from new to wontfix

    If thinking-sphinx requires Rails.root to be set, it needs to create a Rails::Railtie for it and setup the proper initializers. I don't think Rails.root should raise an error. It's ok for it to be nil until it's set.

    February 21st, 2010 @ 11:51 AM

  3. codesnik
    codesnik

    thank you. is there any guide for upgrading gems to rails3, where this
    change is explicitly stated? And if not an exception, maybe some
    deprecation warning would work. If some gem requests Rails.root before
    it is set, it is an error, for sure, and it is a pretty common error.
    And it could be dangerous.

    I've managed to spend a half of a hour with debugger trying to
    understand what's going on, and still didn't get that I need to create
    Rails::Railtie for it.

    February 21st, 2010 @ 03:46 PM

  4. macario
    macario

    Maybe Rails should provide to gems a hook to defer actions after Application is defined. Meanwhile above workaround is not a too bad solution.

    February 25th, 2010 @ 12:27 AM

  5. codesnik
    codesnik

    any gem's custom Rails::Railtie subclass provides such a hook.
    What I didn't get is how can I fix such a gem, not breaking rails2 compatibility. Maybe check for defined?(Rails::Railtie)..

    February 25th, 2010 @ 12:33 AM