On Wednesday 16 April 2008 10:05:01 pm Donavan Pantke wrote: > So, we were messing around with Passenger for rails recently, and ran into > some behavior that I think needs to be addressed, but I'm not sure how. > > Gems, I think as of 1.0, automatically activates a gem's dependencies based on > what its spec says. However, the gem itself has no control over this. This > makes life really hard on systems that need specific handling. In the case of > Passenger, the rails gem is loaded based on the version requested, and more > than one can be loaded (the process forks before rails gets loaded, allowing > multiple versions to be in memory and accessible). However, if the gemspec > has rails in it, activating passenger means that rails automatically gets > activated, and so any further rails activation with a different version > fails. However, the gemspec is entirely correct in that it needs > _some_version of rails, but it really needs to do the activating of the > dependency itself. > > The first question I have is, what mechanism can be made available to avert > activating a dependent gem until the gem actually needs it?
I took a look back, and prior RubyGems had an autorequire option, that was false by default. However, this behavior is not only true by default, but there's no longer even a way of disabling it. I'm thinking that given the new codebase, the best way of carrying forward this behavior is by extending Gem::Dependency and add_dependency to allow for disabling autoloading. This way the developer could control autoloading on a per-dependency basis. This handles especially well the case where a gem has to turn off certain dependencies, but more often than not autoloading is fine. > > The next, bigger question IMO is, what should be the default? I can think of > code paths where loading by default would make it really difficult for people > needing deferred loading, but I may be overestimating the scope. > > So what do you guys think? I can help to write up the code, but I wanted input > on what to write. :) > Thanks! Donavan _______________________________________________ Rubygems-developers mailing list [email protected] http://rubyforge.org/mailman/listinfo/rubygems-developers
