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

Difference between v1 and v2 lock files #6993

Closed
p-mongo opened this issue Feb 27, 2019 · 4 comments · Fixed by #6996
Closed

Difference between v1 and v2 lock files #6993

p-mongo opened this issue Feb 27, 2019 · 4 comments · Fixed by #6996

Comments

@p-mongo
Copy link

p-mongo commented Feb 27, 2019

Given the issues people have with bundler 2 (#6784, rubygems/rubygems#2661), what exactly are the differences between v1 and v2 lock files that v2 lock files cannot be used by bundler v1?

Because I have this diff that made my lock file unusable:

diff --git a/mongoid-app/Gemfile.lock b/mongoid-app/Gemfile.lock
index b87758e..52eda2d 100644
--- a/mongoid-app/Gemfile.lock
+++ b/mongoid-app/Gemfile.lock
@@ -93,7 +93,7 @@ GEM
     mini_mime (1.0.1)
     mini_portile2 (2.4.0)
     minitest (5.11.3)
-    mongo (2.7.0)
+    mongo (2.7.1)
       bson (>= 4.4.2, < 5.0.0)
     mongoid (7.0.2)
       activemodel (>= 5.1, < 6.0.0)
@@ -208,4 +208,4 @@ DEPENDENCIES
   web-console (>= 3.3.0)
 
 BUNDLED WITH
-   1.17.3
+   2.0.1

According to https://bundler.io/blog/2019/01/03/announcing-bundler-2.html Bundler 2 does not have any new features.

@deivid-rodriguez
Copy link
Member

Hei @p-mongo! You are right, bundler 1 and bundler 2 lockfile format should be compatible, and we decided to downgrade those hard errors to warnings for the time being. See #6996.

We still believe that the best way to use bundler is that an application always stick with the same version everywhere. It's not only about lockfile format compatibility, but about making the resolution use the exact same code that resolved the dependencies initially, so it's guaranteed to be the same.

But we acknowledge that we need to do this in a more user-friendly way, so that's why we're downgrading this to a warning.

@p-mongo
Copy link
Author

p-mongo commented Feb 27, 2019

Lock file incompatibility is actually preventing bundler 2 adoption because it is easier to downgrade the one machine that accidentally got bundler 2 installed on it to bundler 1 than to constantly deal with harassment from bundler everywhere else, especially since bundler 2 appears to have no significant new features.

Regarding resolution differences, since there is a lock file, what resolution is going on? Bundler should install the versions that the lock file specifies.

@deivid-rodriguez
Copy link
Member

Lock file incompatibility is actually preventing bundler 2 adoption because it is easier to downgrade the one machine that accidentally got bundler 2 installed on it to bundler 1 than to constantly deal with harassment from bundler everywhere else, especially since bundler 2 appears to have no significant new features.

I understand that, and we're working on fixing these issues, there's not much more I can say 🤷‍♂️.

Regarding resolution differences, since there is a lock file, what resolution is going on? Bundler should install the versions that the lock file specifies.

This not only applies to bundle install with an existing lock file, but to every situation where bundler is used. We would like to enforce that the exact same version is used all the time so all executions of bundler will lead to the same results.

@p-mongo
Copy link
Author

p-mongo commented Feb 28, 2019

I understand, thanks.

ghost pushed a commit that referenced this issue Apr 27, 2019
6996: Downgrade version mismatches to warnings r=indirect a=deivid-rodriguez

Closes #6993.
Complements rubygems/rubygems#2621.

### What was the end-user problem that led to this PR?

The problem was that bundler 2 has become too unfriendly because it errors out when the running version does not match the version in the BUNDLED WITH section in the lockfile.

### What was your diagnosis of the problem?

My diagnosis is that we still believe that making sure the exact same bundler version is always run for a specific application is a good thing, because it ensures resolution is always the same because it's resolved by the exact same code that generated the lockfile.

BUT, we need to ensure this in a more user friendly way, for example by auto-switching and auto-installing the right bundler version without any user intervention.

### What is your fix for the problem, implemented in this PR?

My fix is to downgrade this hard error to a warning that does not prevent bundler from running.



### Why did you choose this fix out of the possible options?

I chose this fix because it still shows the mismatch but allows bundler to run, thus being a bit friendlier. Hopefully this won't be needed once bundler is smart enough to autoswitch and autoinstall.


Co-authored-by: David Rodríguez <deivid.rodriguez@riseup.net>
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
None yet
Projects
None yet
Development

Successfully merging a pull request may close this issue.

3 participants