On Feb 17, 2011, at 12:48 , James Tucker wrote: > 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.
I don't believe this is true and need a test case that proves it to be so. Specifically, I don't think you need to activate the dependencies when you activate a gem. By activating dependencies, you're expecting resolution to be done all at once for the transitive closure of that part of the dep tree and that locks in versions that might not otherwise be locked in. The biggest problem that we had with our dependency resolution (install and gem activation) was that it was eager and single pass. For the installer it was easy to make it 2 phase but for gem activation it was nearly impossible to do such a thing. Instead, I made it lazy by not activating the full transitive closure. This seems to have fixed most, if not all, of the problems we've had in the past... But given that we didn't have a single activation test when I started on this quest, I'm sure we're missing stuff. More tests are very very welcome. _______________________________________________ Rubygems-developers mailing list http://rubyforge.org/projects/rubygems Rubygems-developers@rubyforge.org http://rubyforge.org/mailman/listinfo/rubygems-developers
