You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
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:
ifENV['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:
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
The text was updated successfully, but these errors were encountered:
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 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
orbundle update
withDEPENDENCIES_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: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:
SKIP_BUNDLER_AUTOSYNC
)nothing_changed?
check so that Gemfile_next.lock will be updated even whenGemfile.lock
hasn't changed (and vice-versa)update!
logic to preserve existing env vars, allowing calls likeDEPENDENCIES_NEXT=1 bundle install
to also update Gemfile.lockThis allows for the following combinations:
DEPENDENCIES_NEXT
)SKIP_BUNDLER_AUTOSYNC=1 bundle install
will update Gemfile.lock individuallySKIP_BUNDLER_AUTOSYNC=1 DEPENDENCIES_NEXT=1 bundle install
will update Gemfile_next.lock individuallybundle install
andDEPENDENCIES_NEXT=1 bundle install
will update both Gemfile.lock and Gemfile_next.lockDEPENDENCIES_PREVIOUS
)SKIP_BUNDLER_AUTOSYNC=1 bundle install
will update Gemfile_next.lock individuallySKIP_BUNDLER_AUTOSYNC=1 DEPENDENCIES_PREVIOUS=1 bundle install
will update Gemfile.lock individuallybundle install
andDEPENDENCIES_PREVIOUS=1 bundle install
will update both Gemfile.lock and Gemfile_next.lockThe text was updated successfully, but these errors were encountered: