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

Unexpected behaviour when auto-syncing Gemfiles #25

Open
Illianthe opened this issue May 9, 2019 · 0 comments
Open

Unexpected behaviour when auto-syncing Gemfiles #25

Illianthe opened this issue May 9, 2019 · 0 comments

Comments

@Illianthe
Copy link

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
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

No branches or pull requests

1 participant