Skip to content

Set 'BUNDLE_LOCKFILE' to user's lock file - #431

Merged
g-arjones merged 1 commit into
bundler-4from
set_bundle_lockfile_env_var
Feb 26, 2026
Merged

g-arjones merged 1 commit into
bundler-4from
set_bundle_lockfile_env_var

Conversation

@g-arjones

Copy link
Copy Markdown
Contributor

This is also required on Bundler 4.0.4+

@g-arjones
g-arjones requested a review from doudou February 18, 2026 17:26
@g-arjones

Copy link
Copy Markdown
Contributor Author

@doudou Implemented this on top of your bundler-4 branch, but feel free to change the base if you want.

@g-arjones
g-arjones force-pushed the set_bundle_lockfile_env_var branch from 6079dcf to dd2dccc Compare February 18, 2026 17:29
@doudou

doudou commented Feb 24, 2026

Copy link
Copy Markdown
Member

The default lockfile is not GEMFILE.lock anymore ?

@g-arjones

g-arjones commented Feb 24, 2026 •

Copy link
Copy Markdown
Contributor Author

It is, but require 'bundler/setup' now sets BUNDLE_LOCKFILE explicitly in the shims. Then, when BundlerManager initializes the environment and sets BUNDLE_GEMFILE to prefix/gems/Gemfile, we end up with one pointing to the user Gemfile and the other to the internal lock file.

To make matters even worse, if we only set BUNDLE_LOCKFILE in BundlerManager#initialize_environment and not in the shims, when you source env.sh you will have BUNDLE_LOCKFILE pointing to the user's lock file and BUNDLE_GEMFILE pointing to the internal gem file (set in the shim) which will cause bundler to refuse to load completely due to missing gems in the lock file.

@g-arjones
g-arjones merged commit 741e851 into bundler-4 Feb 26, 2026
6 checks passed
@g-arjones
g-arjones deleted the set_bundle_lockfile_env_var branch February 26, 2026 17:38
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants