On Feb 16, 2011, at 6:27 AM, Luis Lavena wrote: > On Wed, Feb 16, 2011 at 8:44 AM, Ryan Davis <ryand-r...@zenspider.com> wrote: >> With 1.4 our focus was on cleaning up our house and getting a long overdue >> release out. >> >> With 1.5 our focus was on cleaning up the mess in mri 1.9. >> >> And 12 days from now I plan on releasing 1.6. >> >> I've focused on revamping dependency resolution to make it more accurate. I >> just got our last failing test to pass. This probably just means that we're >> missing failing tests. We need as many eyeballs on these changes as possible. >> > > With this new dependency resolution tests, are we considering the "use > cases" of Bundler?
Well, it's sort of what the resolver does, only the resolver takes multiple requirements and merges down, in this case, we start from a single head. The two approaches can be proven equivalent, as you'd just need to create a virtual-head with the same requirements as the multiple requirements you would give to bundlers resolver. > I've tried to look at Bundler gem activation specs (or the reason > bundler exist) and couldn't find a single one. This is a common misconception. Bundler addresses more than just resolution. When I discussed this with some of their team, they said that the failure cases are actually encoded in other tests, and there's good example sets in the gem repository that is setup in the test support. That is build_repo* from here: https://github.com/carlhuda/bundler/blob/1-0-stable/spec/support/builders.rb > Ideally would like RubyGems is a bit smarter in relation to dependency > resolution, like not pulling the latest version of a gem unless > needed... I'm not sure how you can do that. This idea seems to have been floating around for a while, but it's actually invalid. You can't lazy activate dependencies without breaking code. When someone requires a file which is discovered to be in an unactivated gem, you must first activate that gem (and it's dependencies) before you require the file. The reason for this is that otherwise subsequent requires or Kernel#load calls may do the wrong thing. This is why a manifest is absolutely required in order to do correct deep-conflict resolution. The good thing will be however, that rubygems will no longer fail to do this correctly with heads that have complex dependency trees that conflict. >> Please poke at it and report any bugs you find. The easiest way to do this >> would be to install from git by running setup.rb. DO NOT DO THIS if you plan >> on releasing any gems between now and the actual release. Package them. Poke >> at them. But don't release them. I'm pretty sure there are more cases that I wasn't able to cover in my drunken state at Rubyconf. I'm not sure I'll have time this week, if/when I do, I'll provide more cases. _______________________________________________ Rubygems-developers mailing list http://rubyforge.org/projects/rubygems Rubygems-developers@rubyforge.org http://rubyforge.org/mailman/listinfo/rubygems-developers
