Depsolver install suboptimal versions when circular dependencies occur

[ksubrama]

We ran into this in chef-boneyard/chef-dk#506 (comment)

A repro for you would be to clone chef/chef-provisioning-vagrant and attempt to bundle install --without development . The crucial issue is that chef-12.4.1, chef-config-12.4.1, ohai-8.5.1 and ohai-8.6.0 are released gems right now but ohai-8.6.0 needs chef-config >= 12.5 which allows it to only be satisfied if a prerelease gem is installed. chef just wants some ~> 8 version of ohai but each gem is version matched with chef-config (i.e. chef-12.4.1 depends exactly on chef-config-12.4.1). What should happen is that bundler should attempt to solve with either a lower version of chef/chef-config or a lower version of ohai and hopefully, it should settle on chef-12.4.1, chef-config-12.4.1, ohai-8.5.1. Currently, it settles on chef-12.4.0, chef-config-12.4.0, ohai-8.5.1 which is sub-optimal. In some cases, I've seen it settle on chef-12.3.0 depending on the order in which the dependencies are listed.

I pointed out a commit which might fix it (I haven't quite tried it with bundler out of master) but when I do, I'll update this bug and let you know if that fixes in. In the mean time, consider this a +1 for a request for a new release assuming the new depsolver does fix our issue.

[segiddins]

If you need a pre-release gem, there needs to be a dependency that includes a pre-release identifier.

[ksubrama]

I didn't need a prerelease gem. I just needed the depsolver to give me a more recent version of the gem. I confirmed that running bundler from #3862 fixes my issue because of the new version of Molinillo. See https://gist.github.com/ksubrama/bb9818104592b8cc9011

Note how bad-output (bundler 1.10.6) shows an unwind where bundler no longer considers chef-12.4.1 as a viable candidate. The patch-output was run from the merge commit on the PR above and it correctly resolves chef-12.4.1 as the most recently released viable candidate.

[agis]

Fixed by #3862.