On Feb 17, 2011, at 5:48 PM, Ryan Davis wrote: > > 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.
Ok, I thought about it, and stand corrected, providing the semantics are presumably that the requirements set forth by a parent dependent affect any future activation of dependencies. I'm not sure how well this will play out with top-level require-happy libraries, but I could see cases where it might work. If I remember the code order correctly, it wouldn't solve the rack, thin and sinatra issue, or the datamapper issues. Those would still conflict using lazy activation, because the libraries are actually Kernel#require'd prior to the conflict arising. An ahead of time resolution can still solve those cases. I think we did cover one of those examples in discussions at Rubyconf, I'm not sure if we made a test. A specific example is available in the 'gem lock' discussion on this ML. > 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. I'll see if I can make the time. _______________________________________________ Rubygems-developers mailing list http://rubyforge.org/projects/rubygems Rubygems-developers@rubyforge.org http://rubyforge.org/mailman/listinfo/rubygems-developers
