Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Already on GitHub? Sign in to your account

Infinite loop in resolver #2248

Closed
dblock opened this Issue Jan 14, 2013 · 5 comments

Comments

Projects
None yet
2 participants
Contributor

dblock commented Jan 14, 2013

Used instructions in https://github.com/carlhuda/bundler/blob/master/ISSUES.md to make a clean bundle. Bundler hangs. See https://gist.github.com/4534522 for Gemfile, version details and a dependency tree output from bundler.

Owner

indirect commented Jan 15, 2013

How long did it run for? What about the rest of the stuff in ISSUES? Did you try running DEBUG_RESOLVER=true bundle install?

Contributor

dblock commented Jan 15, 2013

The gist has all the output that you ask for in ISSUES, see below the Gemfile.

It runs forever, really. I modified bundler code to output a dependency tree and you can see in the gist that it loops (seems to be related to the builder gem, which doesn't have a .gemspec???). With DEBUG_RESOLVER i get a TON of output, not very helpful, but I can dump it if you want.

Contributor

dblock commented Jan 15, 2013

I think this one is a smaller repro:

source "http://rubygems.org"

gem "rails", "~> 3.2"
gem "builder", "~> 3.1.4"
gem "thin", "1.5.0"
gem "grape", "0.2.6"
Owner

indirect commented Jan 15, 2013

Awesome, thanks! I'll check this out soon.

On Jan 14, 2013, at 4:30 PM, "Daniel Doubrovkine (dB.)" notifications@github.com wrote:

I think this one is a smaller repro:

source "http://rubygems.org"

ruby '1.9.3'

Encoding.default_external = Encoding::UTF_8
Encoding.default_internal = Encoding::UTF_8

gem "rails", "> 3.2"
gem "builder", "
> 3.1.4"
gem "thin", "1.5.0"
gem "grape", "0.2.6"

Reply to this email directly or view it on GitHub.

Contributor

dblock commented Jan 16, 2013

I think this is the problem: if you take all versions of railties, actionmailer, activeresource, activerecord, activesupport and activemodel and try every single combination, it's ... a lot of combinations. All of them bump against a builder gem conflict, so this goes on for a very long time.

matching versions for railties (= 3.2.5) ruby: ["railties (3.2.5)"]
matching versions for actionmailer (= 3.2.5) ruby: ["actionmailer (3.2.5)"]
matching versions for activeresource (= 3.2.5) ruby: ["activeresource (3.2.5)"]
matching versions for activerecord (= 3.2.5) ruby: ["activerecord (3.2.5)"]
matching versions for activesupport (= 3.2.5) ruby: ["activesupport (3.2.5)"]
matching versions for activemodel (= 3.2.5) ruby: ["activemodel (3.2.5)"]
conflicts: ["["builder", [[#<Gem::Specification name=builder version=3.1.4>], builder (~> 3.0.0) ruby]]"]

I am not sure how this can possibly be resolved with the current algorithm. Maybe there should be a limit at how many times the same conflict can surface and you get a warning?

@indirect indirect closed this Feb 25, 2013

This was referenced Jan 10, 2014

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment