[PATCH] Kernel#dependency is broken in 0.5! Loading only from Merb.root / gems blocks loading other dependent gems from system.

I think I've found the problem -- when a gem in the local gems folder requires (dependency) a gem that is not in that gems folder, the second gem is not found, resulting in the first gem NOT loading from the gems folder.

I'm wondering if we could simply make the gems folder take precedence over the rest... Reading the rdoc documentation -- when a gem is required, it could be any of the same version randomly. It sorts by name, then version, then floats ruby platform gems to the top. So if there are a few that are the same, it doesn't care. It looks like the best cure would be to overwrite the Gem::Specification#sort_obj method to include a test for installation_path == Merb.root / "gems". If I get it to work, I'll post a patch.

I don't know how to test the success of this, but here's my suggestion -- run this so that Gem puts your Merb.root / "gems" gems at the top, then use the old-fashioned dependency method instead of the fancy new one.

class Gem::Specification
  def sort_obj
    .@name, installation_path == Merb.root / 'gems' ? -1 : 1, @version.to_ints, @new_platform == Gem::Platform::RUBY ? -1 : 1]
  end
end

Ok, Monday rolls around, I've tested this out and it looks like all's good except for switching the -1 and the 1 in that example above. Replacing the top of the core_ext/kernel.rb file in merb core with the following code seems to work great:

module Gem
  class Specification
    def sort_obj
      .@name, installation_path == Merb.root / 'gems' ? 1 : -1, @version.to_ints, @new_platform == Gem::Platform::RUBY ? -1 : 1]
    end
  end
end

module Kernel
  # Loads the given string as a gem.
  # An optional second parameter of a version string can be specified and is passed to rubygems.
  # If rubygems cannot find the gem it requires the string as a library.
  
  # Note that this new version tries to load the file via ROOT/gems first before moving off to
  # the system gems (so if you have a lower version of a gem in ROOT/gems, it'll still get loaded)
  
  def dependency(name, *ver)
    begin
      Gem.activate(name, true, *ver)
      Merb.logger.info("#{Time.now.httpdate}: loading gem '#{name}' from #{__app_file_trace__.first} ...")
    rescue LoadError
      require name
    end
  end
  ...

Of course that "Gem" extension probably shouldn't go in kernel.rb, so I'll leave that up to whoever should make that decision. My testing shows that this works perfectly except for the following quirk: I had two versions of a gem in my gems folder, and it chose the earlier version. I didn't see it do that anywhere except in the gems directory, so as long as there is only one version of a gem installed in a gems directory, it's happy.

May I ask why "The Future"? I'd like to argue that this is rather an almost-critical bug. I know at least 3-4 people who aren't trying merb yet because of this bug. Rails developers are used to freezing vendor items (gems) in their project, and this bug essentially breaks the whole reason for the gems folder! Can this be included asap?

Because I'm releasing 0.5.3 today, and I don't feel good about putting this into it untested. This point release is probably the last 0.5.x release, so I'm moving all tickets on 0.5.x to The Future, unless they're getting included today.

If you can get some folks to test this patch before I release, I'm happy to consider including it.

Let's talk in #merb, if you're there.

I just upgraded to merb-0.5.3, and a bunch of things broke. First of all ActiveSupport? was trying to load the Application constant, who knows why.. when I disabled ActiveSupport? from the project, it couldn't find the datamapper sessions plugin (which should be in merb_datamapper-0.5).

Anyway, all to say when I put this patch back in to 0.5.3, everything just jumped back on track! I hope more people test this soon!

Solves all dependency / gems folder problems.

UPDATE - the Gems package really isn't written that well.

I found that it will drop out of its index all but reference to one gem of a certain name and version. So I added an overwrite of one more method that will ensure gems from the gems directory are not forgotten.

Here's an updated patch, rewritten with lots of study and digging behind it. Until rubygems undergoes a full rewrite, this patch will suffice. I'd like to suggest a "local gems" feature be added to the rubygems library. This patch is definitely reliable. Use it.

This worked for me right away, thanks...

Sorry to be a bother, but is this going to be looked at and included soon? I do believe many people are having troubles with the latest merb release because of this problem -- everyone I know has (or would have, if I didn't direct them to this patch) reverted back to the previous merb release just because of this problem. Can I say it's a blocker? Who can update their projects that depend on local gems if this dependency loader seldom works at all?

I just closed a duplicate of this issue, #494

Also, I've contacted Eric Hodel of the RubyGems? project to ask about getting this feature built into RubyGems? instead of requiring it to be hacked in -- it's a useful feature for any project that uses gems, not just Merb.

moved to http://merb.lighthouseapp.com