This repository has been archived by the owner on Apr 14, 2021. It is now read-only.
Implicit lock preservation #3722
Merged
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
|
LGTM. 🚢 |
|
|
||
| def lockfiles_equal?(current, proposed, preserve_bundled_with) | ||
| if preserve_bundled_with | ||
| pattern = /\n\nBUNDLED WITH\n.*\n/ |
There was a problem hiding this comment.
Might be better as a constant.
There was a problem hiding this comment.
use the parser constant for BUNDLED WITH, and also the Gem::Version::VERSION_PATTERN constant for the next line (and with \w+ before it instead of .*)
|
Makes sense 👍 |
| it "does not change the lock" do | ||
| lockfile lock_with(Bundler::VERSION.succ) | ||
| bundle :check | ||
| lockfile_should_be lock_with(Bundler::VERSION.succ) |
There was a problem hiding this comment.
please verify the warning is still printed
There was a problem hiding this comment.
It does at least make sense to me to print the warning here, but I feel like I would rather not warn on bundle check than add a third special case to the BUNDLED WITH code :/
There was a problem hiding this comment.
Ironic after my last comment, but the existing behavior is my preferred one: the check command warns, but bundler/setup does not.
indirect
force-pushed
the
implicit_lock_preservation
branch
from
471f876
to
c25d128
Compare
|
Thanks, @indirect ! |
indirect
force-pushed
the
implicit_lock_preservation
branch
from
4e46bb0
to
61738bd
Compare
|
@segiddins there's your specs |
we want to avoid changing the lock just to add BUNDLED WITH unless the user is explicitly running a Bundler command; implicit locking should not alter the lockfile.
When either `bundle check` is run, or any application requires the `bundler/setup` file, Bundler will automatically check whether it is possible to lock the Bundle. During the lock process, Bundler updates the lock if the implicit locking changes the lock file. Starting with the 1.10 release, Bundler includes a lockfile section named BUNDLED WITH that includes the version of Bundler that generated the lockfile. In order to minimize git churn, and guarantee that the lockfile will only be changed when the user runs an explicit Bundler command, Bundler will now only add or update the BUNDLED WITH section during commands where the user asks for changes to the lock. This includes, but is not limited to, `install`, `update`, `lock`, and `package`. Running the `check` command or loading an application that uses Bundler will still now add or update the BUNDLED WITH section if, and only if, the lockfile has also changed for a different reason (such as a gem being updated). Simply using an application, by running `bundle exec` commands or by running `bin/rails` and the like, will not change the lockfile. As a result, the intended workflow with the BUNDLED WITH section is now slightly different than it was before: 1. When running `bundle install`, Bundler will update the version in the lockfile if newer than the version present. 2. Then, check in the lockfile change, exactly as you would after running install to change any other gem version. 3. Older versions of Bundler will not change the number in the lock, but will warn the user that they are out of date. refs rubygems/bundler-features#80 refs #3697
indirect
force-pushed
the
implicit_lock_preservation
branch
from
61738bd
to
14c22c7
Compare
|
Specs are green, so I'm merging this. Thanks for the review, @segiddins! |
Closed
Sign up for free
to subscribe to this conversation on GitHub.
Already have an account?
Sign in.
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
When either
bundle checkis run, or any application requires thebundler/setupfile, Bundler will automatically check whether it is possible to lock the Bundle. During the lock process, Bundler updates the lock if the implicit locking changes the lock file.Starting with the 1.10 release, Bundler includes a lockfile section named BUNDLED WITH that includes the version of Bundler that generated the lockfile. In order to minimize git churn, and guarantee that the lockfile will only be changed when the user runs an explicit Bundler command, Bundler will now only add or update the BUNDLED WITH section during commands where the user asks for changes to the lock. This includes, but is not limited to,
install,update,lock, andpackage.Running the
checkcommand or loading an application that uses Bundler will still now add or update the BUNDLED WITH section if, and only if, the lockfile has also changed for a different reason (such as a gem being updated).Simply using an application, by running
bundle execcommands or by runningbin/railsand the like, will not change the lockfile. As a result, the intended workflow with the BUNDLED WITH section is now slightly different than it was before:bundle install, Bundler will update the version in the lockfile if newer than the version present.refs rubygems/bundler-features#80
refs #3697