Gemfile.lock requirement sort order flapping issue is back

[cgriego]

The previous issue where the Gemfile.lock would flip-flop the order of version constraints seems to be back in force. I'm using Bundler 1.0.18.

@@ -221,7 +219,7 @@ GEM
     faraday (0.7.4)
       addressable (~> 2.2.6)
       multipart-post (~> 1.1.0)
-      rack (>= 1.1.0, < 2)
+      rack (< 2, >= 1.1.0)
     faraday_middleware (0.7.0)
       faraday (~> 0.7.3)
     fastercsv (1.5.4)
@@ -437,10 +435,10 @@ GEM
     tilt (1.3.3)
     timecop (0.3.5)
     tinder (1.6.0)
-      activesupport (>= 2.3, < 4)
+      activesupport (< 4, >= 2.3)
       eventmachine (~> 0.12)
-      faraday (>= 0.6, < 0.8)
-      faraday_middleware (>= 0.6, < 0.8)
+      faraday (< 0.8, >= 0.6)
+      faraday_middleware (< 0.8, >= 0.6)
       hashie (~> 1.0)
       mime-types (~> 1.16)
       multi_json (~> 1.0)
@@ -460,7 +458,7 @@ GEM
     wasabi (2.0.0)
       nokogiri (>= 1.4.0)
     webmock (1.7.4)
-      addressable (~> 2.2, > 2.2.5)
+      addressable (> 2.2.5, ~> 2.2)

[indirect]

Did you happen to change your version of Rubygems, by any chance?

On Aug 27, 2011, at 3:06 PM, cgriego wrote:

The previous issue where the Gemfile.lock would flip-flop the order of version constraints seems to be back in force. I'm using Bundler 1.0.18.

@@ -221,7 +219,7 @@ GEM
    faraday (0.7.4)
      addressable (~> 2.2.6)
      multipart-post (~> 1.1.0)
-      rack (>= 1.1.0, < 2)
+      rack (< 2, >= 1.1.0)
    faraday_middleware (0.7.0)
      faraday (~> 0.7.3)
    fastercsv (1.5.4)
@@ -437,10 +435,10 @@ GEM
    tilt (1.3.3)
    timecop (0.3.5)
    tinder (1.6.0)
-      activesupport (>= 2.3, < 4)
+      activesupport (< 4, >= 2.3)
      eventmachine (~> 0.12)
-      faraday (>= 0.6, < 0.8)
-      faraday_middleware (>= 0.6, < 0.8)
+      faraday (< 0.8, >= 0.6)
+      faraday_middleware (< 0.8, >= 0.6)
      hashie (~> 1.0)
      mime-types (~> 1.16)
      multi_json (~> 1.0)
@@ -460,7 +458,7 @@ GEM
    wasabi (2.0.0)
      nokogiri (>= 1.4.0)
    webmock (1.7.4)
-      addressable (~> 2.2, > 2.2.5)
+      addressable (> 2.2.5, ~> 2.2)

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

[cgriego]

I didn't change rubygems versions between the changes in the sort order. These versions of faraday, tinder, and webmock were installed under the same version of rubygems on the same machine shortly before the order switched.

[cgriego]

Okay, after some more time with it, the behavior I'm seeing isn't flapping. The initial bundle install/update output the requirements the first way and then everything since has held the order steady.

[indirect]

Thanks for letting us know.

On Aug 28, 2011, at 11:20 AM, [email protected] wrote:

Okay, after some more time with it, the behavior I'm seeing isn't flapping. The initial bundle install/update output the requirements the first way and then everything since has held the order steady.

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

[yfeldblum]

I am seeing this too:

     sprockets (2.0.0)
       hike (~> 1.2)
       rack (~> 1.0)
-      tilt (~> 1.1, != 1.3.0)
+      tilt (!= 1.3.0, ~> 1.1)

The pre-diff version is after running bundle update rails (from 3.0.10 to 3.1.0); the post-diff version is after running bundle update shortly thereafter.

[indirect]

I'm not able to reproduce this -- I tried installing with 1.0.17 to create a Gemfile.lock and then running install and then update with 1.0.18. The lockfile didn't change. Can anybody give me some exact repro steps?

[indirect]

So the issue appears to be that Bundler naively trusts the order provided to it by Gem::Requirement#requirements. I just added some code to force those into the order produced by String#<=>, which should mean they can never change order again. Can one of you check out the 1-0-stable branch, run rake install, and test it for me?