This project is archived and is in readonly mode.

#4016 ✓wontfix
codesnik

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

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

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.

Comments and changes to this ticket

  • codesnik

    codesnik February 21st, 2010 @ 02:11 AM

    seems that #4009 addresses the same issue and has a patch. Still, raising exception could make sense

  • José Valim

    José Valim February 21st, 2010 @ 11:51 AM

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

  • codesnik

    codesnik February 21st, 2010 @ 03:46 PM

    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.

  • macario

    macario February 25th, 2010 @ 12:27 AM

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

  • codesnik

    codesnik February 25th, 2010 @ 12:33 AM

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

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

Tags

Referenced by

Pages