Feature idea: Interactive updating of the Gemfile

[andynu]

This library presents such a clear visualization of the updates.

The interactivity especially is an awesome improvement over bundleup's all-or-none prompt.

However, I miss bundleup's --update-gemfile feature. Knowing what is held back because of the pins, and having the ability to update the Gemfile pins would be awesome.

Note that the following gems are being held back:

caxlsx                      3.4.1   → 4.1.0   : pinned at ~> 3.4.1'
rails                       7.0.8.4 → 7.1.3.4 : pinned at ~> 7.0.0 ## core
state_machines-activerecord 0.8.0   → 0.9.0   : pinned at ~> 0.8.0 ## Models
webdrivers                  5.2.0   → 5.3.1   : pinned at >= 5.2.0

It would be cool to be able to say yes, to state_machine-activerecord to accept a change to the pin to move to the next minor release. Or caxlsx to change the pin to the next major. (presumably while retaining the same level of specificity of the ~> pinning).

Anyhow, just an idea. Thank you so much for this commandline utility, it is very nice!

[mattbrictson]

@andynu I agree, this would be a great feature. We could mimic how yarn upgrade-interactive does it: accept a --latest flag that upgrades to the latest versions, regardless of pins. https://classic.yarnpkg.com/lang/en/docs/cli/upgrade-interactive/

# Update lockfile, honoring Gemfile pins
$ bundle update-interactive

# Update lockfile *and* Gemfile, incrementing pins to allow latest versions
$ bundle update-interactive --latest

I've hesitated to build this because doing it reliably would require parsing the Gemfile into an AST and modifying it, and that's an area of Ruby I don't have experience with. (bundleup uses regexes, which works most of the time (?), but runs the risk of corrupting the Gemfile.)

I also wonder if the UI also starts getting complicated. For example, when --latest is passed we could make it a 2-step wizard:

1. Choose which pins to "loosen"
2. Review and select updates as usual

$ bundle update-interactive --latest
Resolving latest gem versions...

2 gems are prevented from being updated to their latest versions.
Would you like to relax these restrictions? Your Gemfile will be modified.

Press <space> to select, ↑/↓ move, <ctrl-a> all, <ctrl-r> reverse, <enter> to finish.
    name                         current   latest  restriction  url
‣ ⬡ caxlsx                       3.4.1   → 4.1.0   ~> 3.4.1     https://...
  ⬡ state_machines-activerecord  0.8.0   → 0.9.0   ~> 0.8.0     https://...

But then, is this not fined-grained enough? E.g. for the caxlsx gem, the user might want to relax to allow next minor (~> 3.5) but not next major (~> 4.0).

Maybe it is best to just display a report of which gems are being held back (like bundleup does), and then leave modifying the Gemfile a manual step for the user?

[andynu]

I think you've identified the key challenge here: People may have very different expectations of a 'default' pin updating behavior. My initial thought was that it would keep the level of pin, and just change the numbers. e.g. from '~> 6.1.0' to '~> 7.1.0' or from '~> 6.1' to '~> 7.1'.

Perhaps just outputting what is held back would be the most informative and least confusing approach.

[mattbrictson]

It is encouraging to hear that the --update-gemfile feature of bundleup is useful, I think this idea is worth pursuing. I have other features I'd like to ship first, but I will definitely keep this in the back of my mind.

[mattbrictson]

Perhaps just outputting what is held back would be the most informative and least confusing approach.

@andynu I implemented a new feature based on our discussion; see #37. If you have a few minutes, please take a look at the PR description and screenshot and let me know what you think. Thanks!

[andynu]

@mattbrictson Yes! This is great.

It shows all the details you need, I love the highlighting based on how serious an upgrade it is and the link to the changelogs. This is so helpful! Thank you.

[mattbrictson]

@andynu FYI, I ended up building the feature that modifies the Gemfile after all; see #42.