Platform regression in 1.1

[sferik]

In bundler 1.1.pre.8 this Gemfile produces the following Gemfile.lock:

PATH
  remote: .
  specs:
    multi_json (1.0.3)

GEM
  remote: http://rubygems.org/
  specs:
    diff-lcs (1.1.3)
    json (1.6.0.1-java)
    rake (0.9.2)
    rdoc (3.9.4)
    rspec (2.6.0)
      rspec-core (~> 2.6.0)
      rspec-expectations (~> 2.6.0)
      rspec-mocks (~> 2.6.0)
    rspec-core (2.6.4)
    rspec-expectations (2.6.0)
      diff-lcs (~> 1.1.2)
    rspec-mocks (2.6.0)
    simplecov (0.5.3)
      multi_json (~> 1.0.3)
      simplecov-html (~> 0.5.3)
    simplecov-html (0.5.3)
    yajl-ruby (1.0.0)

PLATFORMS
  java
  ruby

DEPENDENCIES
  json (~> 1.4)
  multi_json!
  rake (~> 0.9)
  rdoc (~> 3.9)
  rspec (~> 2.6)
  simplecov (~> 0.4)
  yajl-ruby (~> 1.0)

Note: there is no non-java platform version of the json gem in the Gemfile.lock. When I try running bundle exec rake, I get the error:

You have requested:
  json ~> 1.4

The bundle currently has json locked at 1.6.0.1.
Try running `bundle update json`

So, there are a couple problems:

1. This error message is frustrating and not helpful.
2. It looks like @florian/@headius pushed json 1.6.0 and 1.6.0-java; then yanked 1.6.0-java and pushed 1.6.0.1-java, without pushing a 1.6.0.1 (non-java, ruby platform version). That's bad, but bundler should still be able to find the highest version of the json gem that satisfies the dependency for every specified platform (in this case, 1.5.4).

If you need me to add something to rubygems.org API to make this work, please create an issue. Thanks!

Blocker! Blocker! Blocker!

[indirect]

Okay so after checking out this example, I can't get Bundler 1.0 running on jRuby 1.6.4 to behave correctly -- it "updates" to json 1.6.0, which doesn't exist on jruby. So um... ???

[sferik]

I think the bundler 1.0 behavior is less-bad, since it's behaving as if the java version didn't exist, as is the case with many gems.

Bottom line: tests run and pass on 1.0 and fail on 1.1.pre.8.

[headius]

The situation with json is that the 1.6.0 releasr was botched (by me) and since rubygems.org doesn't allow repushing I had to do a 1.6.0.1. That means the only gem that is 1.6.0.1 is the -java version.

What should happen is that the newest gem versions overall should always have priority, and if those gems only exist for platforms the current ruby does not support, then choosing am earlier one is ok. This is what RubyGems does, and Bundler should do the same.

• Charlie (mobile)

On Sep 16, 2011, at 14:32, Andre Arkoreply@reply.github.com wrote:

Okay so after checking out this example, I can't get Bundler 1.0 running on jRuby 1.6.4 to behave correctly -- it "updates" to json 1.6.0, which doesn't exist on jruby. So um... ???

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

[indirect]

Yeah, I agree that that is the "correct" behaviour. Someday, Bundler will do that. :)

On Sep 16, 2011, at 4:13 PM, Charles Oliver Nutter wrote:

The situation with json is that the 1.6.0 releasr was botched (by me) and since rubygems.org doesn't allow repushing I had to do a 1.6.0.1. That means the only gem that is 1.6.0.1 is the -java version.

What should happen is that the newest gem versions overall should always have priority, and if those gems only exist for platforms the current ruby does not support, then choosing am earlier one is ok. This is what RubyGems does, and Bundler should do the same.

• Charlie (mobile)

On Sep 16, 2011, at 14:32, Andre Arkoreply@reply.github.com wrote:

Okay so after checking out this example, I can't get Bundler 1.0 running on jRuby 1.6.4 to behave correctly -- it "updates" to json 1.6.0, which doesn't exist on jruby. So um... ???

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

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