Skip to content
This repository has been archived by the owner on Apr 14, 2021. It is now read-only.

Gemfile.lock Changes Randomly #1081

Closed
benhamill opened this issue Mar 18, 2011 · 27 comments
Closed

Gemfile.lock Changes Randomly #1081

benhamill opened this issue Mar 18, 2011 · 27 comments

Comments

@benhamill
Copy link
Contributor

tl;dr: When loading the project environment (Bundler.setup?) one line in the Gemfile.lock switches places with the line below it.

https://gist.github.com/876573

The above is from a Rails 3 project using bundler 1.0.10 on an Ubuntu 10.10, but I'm seeing similar behavior (a different line in the Gemfile.lock) in other, non-Rails projects that use bundler and on other machines (OS X). I'll continue to play with this an add details as I track it down.

@raggi
Copy link
Contributor

raggi commented Mar 19, 2011

It's not random, it's rails 1.5 - 1.6 ordering differences, I have an unfortunately non-working patch for the issue.

@cgriego
Copy link
Contributor

cgriego commented Mar 21, 2011

@raggi Please explain. I'm uncertain what you're referring to by 1.5 - 1.6 since there was never a version of Rails with those numbers and the reporter says he sees it with Rails 3 and outside Rails projects.

@cgriego
Copy link
Contributor

cgriego commented Mar 21, 2011

Do you mean Rubygems 1.5 - 1.6? I am seeing the Gemfile.lock flip back and forth in order while using Rubygems 1.3.7 exclusively.

@lcowell
Copy link

lcowell commented Mar 22, 2011

To modify the file all I need to do is run: bundle check

-I reset the file using git checkout
-I run bundle check (the file is now modified)
-I commit these changes (the file no longer appears in git status)
-I run bundle check again (the file again appears to be modified)

Because this is happening on one machine, I don't think this can be the result of differing versions of rubygems. I'm running rubygems 1.6.2 and REE 1.8.7 under RVM.

Thanks for all the great work on bundler. I'm sure we'll get this sorted out soon!

@raggi
Copy link
Contributor

raggi commented Mar 26, 2011

This is fixed here:

#1097

@cgriego
Copy link
Contributor

cgriego commented Mar 27, 2011

@raggi Your patch fixes a different issue from the issue reported here. From what I can tell, your patch only affects the ordering of the lock file between parenthesis. The issue reported here is about the order of the lines within the lock file as illustrated by the gist from the opening post.

I just don't want this issue to be prematurely closed by a different issue being fixed.

@h3h
Copy link

h3h commented Mar 30, 2011

I'm also seeing this issue with RubyGems 1.6.2 / bundler 1.0.10 / REE 1.8.7 (2011.03).

Running bundle fixes it every time (resets Gemfile.lock back to its original state that's stored in git), but it's disconcerting to always have the Gemfile.lock file changing for no reason.

@schneems
Copy link
Contributor

Running the same stack as h3h, i have to run bundle before i push to github every time, since the Gemfile.lock changes. I did not get this problem using a previous version of REE.

@mperham
Copy link

mperham commented Apr 1, 2011

I'm seeing this every day too. I assume @raggi's pull req would fix the issue.

+++ b/Gemfile.lock
@@ -245,7 +245,7 @@ GEM
       rubyzip
     sinatra (1.2.1)
       rack (~> 1.1)
-      tilt (>= 1.2.2, < 2.0)
+      tilt (< 2.0, >= 1.2.2)
     spork (0.9.0.rc4)
     symbolize (3.1.2)

Bundler 1.0.10, rubygems 1.6.2, rails 3.0.5, ruby 1.9.2

@h3h
Copy link

h3h commented Apr 1, 2011

+++ b/Gemfile.lock
@@ -61,8 +61,8 @@ GEM
     capistrano (2.5.20)
       highline
       highline
-      net-scp
       net-scp (>= 1.0.0)
+      net-scp

If it's helpful.

@raggi
Copy link
Contributor

raggi commented Apr 1, 2011

My patch fixes mperhams case. It does not fix the net-scp case. I believe @indirect already fixed the net-scp case. If both fixes were rolled into a release, that would be great.

@h3h
Copy link

h3h commented Apr 5, 2011

I'm still seeing the net-scp version of this issue on bundler 1.0.11, FWIW.

@cgriego
Copy link
Contributor

cgriego commented Apr 5, 2011

Same here.

@eric
Copy link
Contributor

eric commented Apr 13, 2011

I've been seeing this with net-scp (like @h3h) on bundler 1.0.10.

@indirect
Copy link
Member

That's correct, the issue with net-scp is resolved in version 1.0.12. Please upgrade.

@schneems
Copy link
Contributor

Upgraded to bundler 1.0.12 and the issue persists:
Gemfile.lock:

- net-scp (>= 1.0.0)
  net-scp
+ net-scp (>= 1.0.0)
- net-ssh (>= 2.0.14)
  net-ssh
+ net-ssh (>= 2.0.14)

The changes in Gemfile.lock do not go away after running bundle

@indirect
Copy link
Member

...how is that a change? the lines are in the same order.

@schneems
Copy link
Contributor

Sorry about that, left out lines (updated previous comment) screenshot: http://yfrog.com/h3vm0cj

@indirect
Copy link
Member

Yes, that is the correct sorting. Check that in, and running bundle install will no longer change the line sorting.

@schneems
Copy link
Contributor

thanks, worked like a charm!

@marceldegraaf
Copy link

I'm still seeing this issue on Bundler 1.0.13. Each time I open a Rails console or run a Rake task, I get a change in Gemfile.lock where net-scp has jumped a line down.

It basically looks like this:

taberna master / $ git status
# On branch master
nothing to commit (working directory clean)

taberna master / $ rails c
Loading development environment (Rails 3.0.5)
ree-1.8.7-2011.03 :001 > exit

taberna master / $ git status
# On branch master
# Changed but not updated:
#   (use "git add <file>..." to update what will be committed)
#   (use "git checkout -- <file>..." to discard changes in working directory)
#
#   modified:   Gemfile.lock

The changes in Gemfile.lock:

taberna master / $ git diff
diff --git a/Gemfile.lock b/Gemfile.lock
index a56d5ea..460f474 100644
--- a/Gemfile.lock
+++ b/Gemfile.lock
@@ -42,8 +42,8 @@ GEM
     capistrano (2.5.20)
       highline
       highline
-      net-scp (>= 1.0.0)
       net-scp
+      net-scp (>= 1.0.0)
       net-sftp
       net-sftp (>= 2.0.0)
       net-ssh

This occurs for me with Ruby Enterprise Edition 1.8.7 (2011.03) and Bundler 1.0.13. Does anybody else see this behavior? What can I do to fix it?

@benhamill
Copy link
Contributor Author

If you leave it in the order with the version number lower, it should stay in that location, I think. indirect indicates that this is the correct order and that it is not consistent.

@marceldegraaf
Copy link

Hm, I've now committed the Gemfile.lock with changed ordering. Will see if it stays unchanged now. Thanks!
On Tuesday, May 10, 2011 at 9:39 PM, benhamill wrote:

If you leave it in the order with the version number lower, it should stay in that location, I think. indirect indicates that this is the correct order and that it is not consistent.

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

garethrees added a commit to mysociety/alaveteli that referenced this issue May 28, 2014
Had issues similar to:

- rubygems/bundler#1375
- rubygems/bundler#1081

Was a problem with the Ubuntu packaged version of bundler. Seems to be resolved
in later versions of bundler.
@fenelon
Copy link

fenelon commented Sep 5, 2014

I've started seeing the same issue a couple of weeks ago. The gems installed from github reshuffle randomly from time to time.

@indirect
Copy link
Member

indirect commented Sep 5, 2014

Please upgrade to Bundler 1.7.2 and report back if the problem still exists.

On Fri, Sep 5, 2014 at 7:06 AM, Ellin Tolstov [email protected]
wrote:

I've started seeing the same issue a couple of weeks ago. The gems installed from github reshuffle randomly from time to time.

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

@fenelon
Copy link

fenelon commented Sep 8, 2014

I'm using Bundler version 1.7.2

@TimMoore
Copy link
Contributor

TimMoore commented Sep 8, 2014

@fenelon please open a new issue and include the output from bundle env so we can try to reproduce your problem. Thanks!

Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
None yet
Projects
None yet
Development

No branches or pull requests