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.

[PATCH] rmagick gem dependency is detected as unbuilt even though it isn't vendored

#2825

Running into a problem with one of my apps where when I update vendor/rails to any commit beyond 4b68debb1c4d3d272b237049c88d01b1eceb58f0 on 2-3-stable, I can no longer run 'rake test' or 'rake db:migrate' et al. I get:

The following gems have native components that need to be built
  rmagick



You're running: ruby 1.8.7.174 at /opt/local/bin/ruby rubygems 1.3.4 at /Users/jd/.gem/ruby/1.8, /opt/local/lib/ruby/gems/1.8


Run
rake gems:build to build the unbuilt gems.

I have this in my environment.rb:

config.gem 'rmagick', :lib => 'RMagick'

But I have the rmagick gem installed (it's not unpacked into vendor/gems), so I'm not sure what's up.

Reported by J.D. Hollis · June 22nd, 2009 @ 10:22 PM

State: resolved
Milestone: 2.x
Assigned to: Matt Jones Matt Jones
Importance: none

Activity

  1. J.D. Hollis
    J.D. Hollis

    Ok, did some digging. For some reason, rmagick is getting added to the list of @@framework_gems in GemDependency when I run 'rake test'. Best I can tell, this is because rmagick is loaded before any of the gem dependencies. Because framework_gem? returns true for rmagick, when GemDependency#add_load_paths is called for rmagick, it marks the gem as frozen (which it isn't). GemDependency#frozen? is memoized, so a proper check is never performed. By changing

    if framework_gem?
      @load_paths_added = @loaded = @frozen = true
      return
    end
    

    to

    if framework_gem?
      @load_paths_added = @loaded = true
      return
    end
    

    the problem goes away.

    June 24th, 2009 @ 07:15 PM

  2. J.D. Hollis
    J.D. Hollis
    • Tag changed from 2-3-stable, gem, gem.config, gems, gem_dependency to 2-3-stable, gem, gem.config, gems, gem_dependency, patch

    And here's the patch against master. (It should apply cleanly to 2-3-stable as well.)

    June 24th, 2009 @ 08:09 PM

  3. J.D. Hollis
    J.D. Hollis
    • Title changed from rmagick gem dependency is detected as unbuilt even though it isn't vendored to [PATCH] rmagick gem dependency is detected as unbuilt even though it isn't vendored

    June 24th, 2009 @ 08:19 PM

  4. Matt Jones
    Matt Jones

    The early freezing was marked to prevent a different situation - users were having issues with gems that were loaded early ("framework gems", as the code calls them) being frozen in vendor but not being used. In your case, even if you froze RMagick to vendor/gems, it would still need (AFAIK) to be installed in the system repository.

    The issue is with the build check - I'll take a look at it.

    June 24th, 2009 @ 09:06 PM

  5. J.D. Hollis
    J.D. Hollis

    Cool—thanks. "framework_gems" is definitely a bit confusing. Would something like "loaded_gems" work better?

    June 24th, 2009 @ 09:24 PM

  6. J.D. Hollis
    J.D. Hollis

    Looking at :built?, I can see three potential strategies (from my admittedly limited point of view). First option is to add an extra vendor_gem? check to the top of the method (essentially saying that if it isn't in vendor/gems, it's not Rails' problem whether it's built or not). Second option would be to check for the extension Makefiles in the actual path of the loaded gem (instead of assuming it's under vendor/gems). Third option would be to refactor and relabel things a bit to make the early freeze (and "framework gems") a bit more understandable.

    First option seems to be the most straight-forward (and most in spirit with what's already there).

    I'd be happy to tackle the patch for any of these.

    June 26th, 2009 @ 06:39 PM

  7. J.D. Hollis
    J.D. Hollis

    Ok—here's a patch against master for my first option described above (a vendor_gem? check in built?).

    June 29th, 2009 @ 09:56 PM

  8. Matt Jones
    Matt Jones

    The only change I'd recommend to that patch is to split out the new test as a separate method - it makes it easier to tell what's going on. Otherwise looks reasonable.

    June 29th, 2009 @ 10:05 PM

  9. Michael Koziarski
    Michael Koziarski
    • Assigned user set to Matt Jones

    June 30th, 2009 @ 12:18 AM

  10. J.D. Hollis
    J.D. Hollis

    Done. This should apply cleanly to both master and 2-3-stable.

    June 30th, 2009 @ 02:00 PM

  11. Repository
    Repository
    • State changed from new to resolved

    July 2nd, 2009 @ 06:30 PM

  12. Repository