bundler improperly selects gem version when binary release is ahead of source release

[cowboyd]

the libv8 gem has a binary release for Lion http://rubygems.org/gems/libv8/versions/3.3.10.3-x86_64-darwin-11 that is a point release ahead of the source and binary gems for all other platforms (libv8-3.3.10.2)

Bundler however, selects libv8-3.3.10.3 as the target version even when running on platforms other than Lion.

Rubygems will correctly install 3.3.10.2 when not on Lion, and 3.3.10.3 when on Lion.

Bundler should have the same dependency resolution semantics as Rubygems.

[indirect]

Bundler's entire reason for existence is to guarantee that you get the gem with the same version number on every platform. If you don't care about that, run "bundle update libv8" on each platform to get the newest possible gem for that platform.

On Nov 14, 2011, at 12:36 PM, Charles Lowell wrote:

the libv8 gem has a binary release for Lion http://rubygems.org/gems/libv8/versions/3.3.10.3-x86_64-darwin-11 that is a point release ahead of the source and binary gems for all other platforms (libv8-3.3.10.2)

Bundler however, selects libv8-3.3.10.3 as the target version even when running on platforms other than Lion.

Rubygems will correctly install 3.3.10.2 when not on Lion, and 3.3.10.3 when on Lion.

Bundler should have the same dependency resolution semantics as Rubygems.

---

Reply to this email directly or view it on GitHub:
#1537

[cowboyd]

In that case, it seems as though Bundler should go with a lowest-common-denominator approach and force 3.3.10.2 on Lion even when a newer binary gem exists, because 3.3.10.3 is not available on other platforms.

[indirect]

Bundler has no idea what platforms you will attempt to install on, and does the best it can with the platform it is on. If you bundle update on a second platform, bundler will look for something that satisfies all the platforms, including those in the lock.

On Nov 14, 2011, at 1:07 PM, Charles Lowellreply@reply.github.com wrote:

In that case, it seems as though Bundler should go with a lowest-common-denominator approach and force 3.3.10.2 on Lion even when a newer binary gem exists, because 3.3.10.3 is not available on other platforms.

---

Reply to this email directly or view it on GitHub:
#1537 (comment)

[cowboyd]

Apologies, I don't think my initial explanation was clear enough (I was trying to bang it out before heading home for the day). Let me try again.

Bundler has no idea what platforms you will attempt to install on, and does the best it can with the platform it is on.

This is my point. That is how it should behave, but it does not.

My contention is not that Bundler should select different gem versions on different platforms. Rather, it should be able to pick some installable version of a gem that satisfies the dependencies regardless of what versions are available on other platforms. In concrete terms:

source 'http://rubygems.org'

gem 'libv8'

This gemfile should resolve properly on a clean bundle install provided there is some version of libv8 that is installable on the current platform, right?

However, today, this simplest of Gemfiles would not install on Ubuntu, CentOS, FreeBSD or Snow Leopard, because the Leopard gem was throwing Bundler off and making it think that a version existed for the current platform which in fact did not.

Does this make more sense?

EDIT: The Lion binary gem has since been yanked, so the above Gemfile will not reproduce the bug anymore.

[indirect]

Ahh, I understand now. Yeah, that seems like a bug to me. Thanks for the explanation!

[cowboyd]

FYI,

I've run into this again with the bson gem

As you can see, there is a 1.4.1-jruby, but the main 1.4.1 was yanked, so now you can't bundle bson on any other platform without specifying 1.4.0.

I've confirmed that this is a problem for both bundler 1.0 and 1.1 series.

[xaviershay]

So is the bug here that when you have a gem in your lock file that is later yanked, you get an error? That seems expected.

Is it that leopard did something Really Weird (tm) that screwed us over, then fixed it? If that happened again I imagine we would try to do a specific temporary fix.

Closing because this is old and I'm not really sure what a good next action is. Please do reopen if you can clarify.