While experimenting with this plugin I ran into a couple of cases that felt a bit unintuitive:
-
Suppose we had an already-existing barebones setup (i.e. Gemfile_next.lock is present) and then we added the following to the Gemfile:
if ENV['DEPENDENCIES_NEXT']
gem 'rspec'
end
Running bundle install alone won't update Gemfile_next.lock as Gemfile.lock never actually changes. Of course if several gems were added simultaneously and at least one was outside that conditional both files will get updated properly.
-
Running bundle install or bundle update with DEPENDENCIES_NEXT already set won't ever modify Gemfile.lock. There are a few cases where we might set that variable globally (e.g. through a .env file with Docker Compose, etc.) and updating Gemfile.lock would require something like:
unset DEPENDENCIES_NEXT
bundle install
export DEPENDENCIES_NEXT=1
Aside from the increase in cognitive load, I'm not sure if the intention was to be able to update each lockfile individually. If that's the case I don't think it's possible to update Gemfile.lock by itself as there's no way to skip the auto-sync process when the environment variable isn't set. One possible fix might be to compare the value of DEPENDENCIES_NEXT rather than checking for its presence.
I took a stab at addressing some of this in master...Illianthe:auto-sync but I figure it'd be worth bringing it up for discussion beforehand:
- Added an env var to skip the auto-sync process (
SKIP_BUNDLER_AUTOSYNC)
- Dropped the
nothing_changed? check so that Gemfile_next.lock will be updated even when Gemfile.lock hasn't changed (and vice-versa)
- Modified the
update! logic to preserve existing env vars, allowing calls like DEPENDENCIES_NEXT=1 bundle install to also update Gemfile.lock
This allows for the following combinations:
- Assuming Gemfile.lock is the default (i.e. using
DEPENDENCIES_NEXT)
SKIP_BUNDLER_AUTOSYNC=1 bundle install will update Gemfile.lock individually
SKIP_BUNDLER_AUTOSYNC=1 DEPENDENCIES_NEXT=1 bundle install will update Gemfile_next.lock individually
bundle install and DEPENDENCIES_NEXT=1 bundle install will update both Gemfile.lock and Gemfile_next.lock
- Assuming Gemfile_next.lock is the default (i.e. using
DEPENDENCIES_PREVIOUS)
SKIP_BUNDLER_AUTOSYNC=1 bundle install will update Gemfile_next.lock individually
SKIP_BUNDLER_AUTOSYNC=1 DEPENDENCIES_PREVIOUS=1 bundle install will update Gemfile.lock individually
bundle install and DEPENDENCIES_PREVIOUS=1 bundle install will update both Gemfile.lock and Gemfile_next.lock
While experimenting with this plugin I ran into a couple of cases that felt a bit unintuitive:
Suppose we had an already-existing barebones setup (i.e. Gemfile_next.lock is present) and then we added the following to the Gemfile:
Running
bundle installalone won't update Gemfile_next.lock as Gemfile.lock never actually changes. Of course if several gems were added simultaneously and at least one was outside that conditional both files will get updated properly.Running
bundle installorbundle updatewithDEPENDENCIES_NEXTalready set won't ever modify Gemfile.lock. There are a few cases where we might set that variable globally (e.g. through a.envfile with Docker Compose, etc.) and updating Gemfile.lock would require something like:Aside from the increase in cognitive load, I'm not sure if the intention was to be able to update each lockfile individually. If that's the case I don't think it's possible to update Gemfile.lock by itself as there's no way to skip the auto-sync process when the environment variable isn't set. One possible fix might be to compare the value of
DEPENDENCIES_NEXTrather than checking for its presence.I took a stab at addressing some of this in master...Illianthe:auto-sync but I figure it'd be worth bringing it up for discussion beforehand:
SKIP_BUNDLER_AUTOSYNC)nothing_changed?check so that Gemfile_next.lock will be updated even whenGemfile.lockhasn't changed (and vice-versa)update!logic to preserve existing env vars, allowing calls likeDEPENDENCIES_NEXT=1 bundle installto also update Gemfile.lockThis allows for the following combinations:
DEPENDENCIES_NEXT)SKIP_BUNDLER_AUTOSYNC=1 bundle installwill update Gemfile.lock individuallySKIP_BUNDLER_AUTOSYNC=1 DEPENDENCIES_NEXT=1 bundle installwill update Gemfile_next.lock individuallybundle installandDEPENDENCIES_NEXT=1 bundle installwill update both Gemfile.lock and Gemfile_next.lockDEPENDENCIES_PREVIOUS)SKIP_BUNDLER_AUTOSYNC=1 bundle installwill update Gemfile_next.lock individuallySKIP_BUNDLER_AUTOSYNC=1 DEPENDENCIES_PREVIOUS=1 bundle installwill update Gemfile.lock individuallybundle installandDEPENDENCIES_PREVIOUS=1 bundle installwill update both Gemfile.lock and Gemfile_next.lock