Bugs item #27867, was opened at 2010-02-22 03:54 You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=575&aid=27867&group_id=126
Category: None Group: None >Status: Closed >Resolution: Rejected Priority: 3 Submitted By: Hongli Lai (hongli) >Assigned to: Ryan Davis (zenspider) Summary: RubyGems should not pre-activate dependencies that have no version requirement Initial Comment: Suppose that we have an app Foo that depends on Bar, no specific version. At this time, running 'gem "foo"' will automatically activate the latest version of "bar". This behavior causes various problems. A concrete example: - Rails 3.0pre depends on Rack 1.1. - Rails 2.3 depends on Rack 1.0. - Thin depends on Rack, no specific version. If all of the above are installed, and one tries to use Thin to start a Rails 2.3 app, then it will fail. Thin's wrapper binary runs 'gem "thin"', which in turn activates Rack 1.1 immediately. When Thin starts Rails 2.3, Rails tries to activate Rack 1.0. As you can see, Thin + Rails 2.3 is completely broken just by having Rack 1.1 installed. This can be solved adding an hypothetical --rack-version=xxx command line option to Thin, which would instruct Thin to activate a specific Rack version during startup so that one can start Rails 2.3 apps with: thin start --rack-version=1.0.0 However this is currently unimplementable because the RubyGems wrapper binary activates Rack during startup. I think it should only check whether Rack is installed, but not actually activate it until it's actually require'ed. See also https://rails.lighthouseapp.com/projects/8994-ruby-on-rails/tickets/4031-having-rails-23pre-or-rack-11-installed-breaks-rails-2x ---------------------------------------------------------------------- >Comment By: Ryan Davis (zenspider) Date: 2010-11-12 17:01 Message: I'm working on revamping activation to deal with this problem, but not with what is suggested here. Closing. ---------------------------------------------------------------------- Comment By: James Tucker (raggi) Date: 2010-02-22 05:18 Message: But Thin doesn't call Kernel#gem, lib/thin.rb requires rack. Arguably there's not really any need for thin to be putting things into the Rack namespace, but that's totally a 3rd party argument. The only way to truly solve this problem is for applications and libraries to present a manifest of their dependencies before any code is loaded, so that a resolver such as the one in bundler can select compatible dependency trees. This will not be popular in the ruby community. Common rejection of Hoe's Manifest.txt is an immediate example. I see this as a social problem, rubyists don't like "complexity" and adding manifests in a separate file, that developers are going to have to track is going to be generally seen as "unnecessary complexity". That being said, bundler is gaining popularity, and it does effectively solve this issue in the manner I am suggesting, albeit in a sealed single application environment. I would think that rubygems supporting dependency manifests and dependency resolution would be a good thing, indeed there is thought going into this, but it will require a carefully crafted API to remain backward and forward compatible, as well as being user friendly. ---------------------------------------------------------------------- You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=575&aid=27867&group_id=126 _______________________________________________ Rubygems-developers mailing list http://rubyforge.org/projects/rubygems Rubygems-developers@rubyforge.org http://rubyforge.org/mailman/listinfo/rubygems-developers
