Skip to content

Fix bundle lock --update <gem> with --lockfile flag updating all gems #8922

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Jump to bottom
Merged
merged 1 commit into from
Aug 26, 2025
Merged

Fix bundle lock --update <gem> with --lockfile flag updating all gems #8922

merged 1 commit into from
Aug 26, 2025
+81 −43

Conversation

@Edouard-chin
Copy link
Contributor

@Edouard-chin Edouard-chin commented Aug 13, 2025

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

See #8917

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

First commit removes the deprecation on Definition#lock where we planned to remove the possibility to pass a path.

Second commit makes use of the first commit and fix the bundle lock command when passed both the --lockfile and --update gem. The lock command now build a definition from an existing lockfile, make the requested changes to the definition and dump its content into the desired lockfile.

Make sure the following tasks are checked

@Edouard-chin Edouard-chin force-pushed the ec-remove-deprecation branch from c96f34c to 18ac3ce Compare August 13, 2025 01:22
@deivid-rodriguez
Copy link
Contributor

deivid-rodriguez commented Aug 13, 2025

Thank you!

I understand that this would be the only way to gracefully transition back to passing a file argument to Definition#lock. However, this makes things quite complicated and leaves us where we were originally, but now with the method parameters reversed.

How about keeping the current deprecation (which should be consolidated in Bundler 4), and instead expose Definition#write_lock to fix the regression?

@deivid-rodriguez deivid-rodriguez linked an issue Aug 13, 2025 that may be closed by this pull request
[Regression] bundle lock --update foo --lockfile unexisting_lockfile.lock now updates *all* gems #8917
Closed
@Edouard-chin
Copy link
Contributor Author

Edouard-chin commented Aug 13, 2025

Yeah I agree that the extra complexity just to get us to where we were is off putting.
Expositing write_lock makes sense 👍 . Are we planning to reintroduce to_lock(path) at some point (e.g. after we have consolidated the current deprecation) ?

@deivid-rodriguez
Copy link
Contributor

deivid-rodriguez commented Aug 13, 2025

I think we never supported to_lock(path) in the past 🤔? I believe write_lock is what we want here: write the current definition, but to a different lockfile, right?

@Edouard-chin Edouard-chin force-pushed the ec-remove-deprecation branch from 18ac3ce to ad0fdef Compare August 14, 2025 20:30
@Edouard-chin
Copy link
Contributor Author

Edouard-chin commented Aug 14, 2025

👍 , nevermind I got confused. I made the change and exposed the write_lock method.

deivid-rodriguez
deivid-rodriguez approved these changes Aug 26, 2025
View reviewed changes
Copy link
Contributor

@deivid-rodriguez deivid-rodriguez left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Makes sense to me, thanks for the fix!

@Edouard-chin @deivid-rodriguez
Fix bundle lock regression when using update and lockfile flags:
c88f00c 
- Ref ruby#8917
- ### Problem

  Prior to Bundler 2.5.6, running
  `bundle lock --update foo --lockfile Gemfile_bumped.lock` would
  update only the foo gem and write the lockfile to the
  `Gemfile_bumped.lock`.

  In Bundler 2.5.6 and above running the same command, updates
  absolutely all gems.
  This change is related to ruby#7047

  ### Solution

  We decided to expose the `write_lock` method rather than going
  through a complex deprecation cycle of the `lock` method.

  This commit applies the same business logic as prios to 2.5.6 where,
  we build the definition using the existing lockfile, make changes to
  the definition and dump it into the desired lockfile.
@deivid-rodriguez deivid-rodriguez merged commit c230844 into ruby:master Aug 26, 2025
76 checks passed
@Edouard-chin
Copy link
Contributor Author

Edouard-chin commented Aug 26, 2025

Thanks David!

@Edouard-chin Edouard-chin deleted the ec-remove-deprecation branch August 26, 2025 20:38
@deivid-rodriguez deivid-rodriguez changed the title Reintroduce the possibility to pass a path on Definition#lock. Also fix bundle lock updating all gems. Fix bundle lock --update <gem> with --lockfile flag updating all gems Sep 1, 2025
deivid-rodriguez added a commit that referenced this pull request Sep 4, 2025
@deivid-rodriguez
Merge pull request #8922 from Edouard-chin/ec-remove-deprecation
da67811 
Reintroduce the possibility to pass a path on `Definition#lock`. Also fix `bundle lock` updating all gems.

(cherry picked from commit c230844)
deivid-rodriguez added a commit that referenced this pull request Sep 9, 2025
@deivid-rodriguez
Merge pull request #8922 from Edouard-chin/ec-remove-deprecation
a3a0cda 
Reintroduce the possibility to pass a path on `Definition#lock`. Also fix `bundle lock` updating all gems.

(cherry picked from commit c230844)
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Reviewers

1 more reviewer

@deivid-rodriguez deivid-rodriguez deivid-rodriguez approved these changes

Reviewers whose approvals may not affect merge requirements

Assignees

No one assigned

Labels

bundler: bug fix

Projects

None yet

Milestone

No milestone

Development

Successfully merging this pull request may close these issues.

[Regression] bundle lock --update foo --lockfile unexisting_lockfile.lock now updates *all* gems

2 participants

@Edouard-chin @deivid-rodriguez