Skip to content
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.

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

don't evaluate the default lockfile at all in certain cases #20

Merged
merged 1 commit into from
Dec 21, 2023
Merged
Show file tree
Hide file tree
Changes from all commits
Commits
File filter

Filter by extension

Filter by extension

Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
27 changes: 27 additions & 0 deletions README.md
Original file line number Diff line number Diff line change
Expand Up @@ -88,6 +88,33 @@ BUNDLE_LOCKFILE=rails-7.0 bundle exec rspec
You can also dynamically select it in your Gemfile, and pass `current: true`
to (exactly one!) `lockfile` method.

In some cases, you may want to essentially disable bundler-multilock's
syncing behavior, while still allowing the Gemfile to select the active
lockfile. For example, if you have gems in the default lockfile that cannot
be installed under a certain Ruby version, but still want to be able to CI
against that Ruby version, you may set it up like this:

```ruby
lockfile active: RUBY_VERSION >= "2.7" do
gem "debug", "~> 1.9"
end

lockfile "ruby-2.6", active: RUBY_VERSION < "2.7" do
gem "debug", "~> 1.8.0"
end
```

However, you cannot run a regular `bundle install` while running Ruby 2.6 in
this situation, since simply evaluating the default lockfile's block, even
for checking that the lockfiles are valid, will raise an exception that debug
1.9.0 require Ruby 2.7. You could set `BUNDLE_LOCKFILE=ruby-2.6` to have
bundler-multilock only consider the one lockfile, but then your CI may need
additional logic to _not_ set it for other Ruby versions. Instead, you can
set `BUNDLE_LOCKFILE=active`, which will not override the Gemfile's selection
of which lockfile is active, but still behave as if `BUNDLE_LOCKFILE` is set,
bypassing any other syncing logic and not evaluating the default lockfile in
our example.

## Comparison to Appraisal

[Appraisal](https://github.com/thoughtbot/appraisal) is a gem that might serve
Expand Down
3 changes: 2 additions & 1 deletion lib/bundler/multilock.rb
Original file line number Diff line number Diff line change
Expand Up @@ -60,7 +60,8 @@ def add_lockfile(lockfile = nil,
raise ArgumentError, "Lockfile #{lockfile} is already defined"
end

env_lockfile = ENV["BUNDLE_LOCKFILE"]&.then { |l| expand_lockfile(l) }
env_lockfile = lockfile if active && ENV["BUNDLE_LOCKFILE"] == "active"
env_lockfile ||= ENV["BUNDLE_LOCKFILE"]&.then { |l| expand_lockfile(l) }
active = env_lockfile == lockfile if env_lockfile

if active && (old_active = lockfile_definitions.find { |definition| definition[:active] })
Expand Down
19 changes: 19 additions & 0 deletions spec/bundler/multilock_spec.rb
Original file line number Diff line number Diff line change
Expand Up @@ -736,6 +736,25 @@
end
end

it "does not evaluate the default lockfile at all if an alternate is active, " \
"without specifying that lockfile explicitly" do
with_gemfile(<<~RUBY) do
gem "inst-jobs", "3.1.13"
lockfile active: ENV["ALTERNATE"] != "1" do
raise "evaluated!" if ENV["ALTERNATE"] == "1"
end
lockfile "alt", active: ENV["ALTERNATE"] == "1" do
gem "activerecord-pg-extensions"
end
RUBY
invoke_bundler("install")

invoke_bundler("install", env: { "ALTERNATE" => "1", "BUNDLE_LOCKFILE" => "active" })
end
end

private

def create_local_gem(name, content = "", subdirectory: true)
Expand Down