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

Closed
cowboyd opened this Issue Nov 14, 2011 · 7 comments

Comments

Projects
None yet
3 participants
@cowboyd
Contributor

cowboyd commented Nov 14, 2011

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

This comment has been minimized.

Show comment Hide comment
@indirect

indirect Nov 14, 2011

Member

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:
carlhuda#1537

Member

indirect commented Nov 14, 2011

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:
carlhuda#1537

@cowboyd

This comment has been minimized.

Show comment Hide comment
@cowboyd

cowboyd Nov 14, 2011

Contributor

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.

Contributor

cowboyd commented Nov 14, 2011

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

This comment has been minimized.

Show comment Hide comment
@indirect

indirect Nov 14, 2011

Member

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:
carlhuda#1537 (comment)

Member

indirect commented Nov 14, 2011

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:
carlhuda#1537 (comment)

@cowboyd

This comment has been minimized.

Show comment Hide comment
@cowboyd

cowboyd Nov 15, 2011

Contributor

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.

Contributor

cowboyd commented Nov 15, 2011

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

This comment has been minimized.

Show comment Hide comment
@indirect

indirect Nov 15, 2011

Member

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

Member

indirect commented Nov 15, 2011

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

@cowboyd

This comment has been minimized.

Show comment Hide comment
@cowboyd

cowboyd Nov 23, 2011

Contributor

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.

Contributor

cowboyd commented Nov 23, 2011

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

This comment has been minimized.

Show comment Hide comment
@xaviershay

xaviershay Aug 11, 2013

Contributor

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.

Contributor

xaviershay commented Aug 11, 2013

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.

@xaviershay xaviershay closed this Aug 11, 2013

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