Interactive .tool-version updates

[timdp]

Is your feature request related to a problem? Please describe

If you like to use latest-and-greatest, updating .tool-versions files with the right versions of individual tools can get pretty tedious.

Describe the proposed solution

The Yarn package manager for JavaScript has an upgrade-interactive command that provides a list of radio buttons for available upgrades. Here's an (outdated) example from a random blog post about it:

I think this would be a good fit for asdf as well. Ultimately, I feel like it's a phase in the life of every package manager out there.

To get a feel for it, I wrote asdf-bump in JS. It's just a proof of concept but it does work for me. (I initially wanted to create a PR but as comfortable as I am with Bash, it was a lot easier to do in JS.)

Describe similar asdf features and why they are not sufficient

• asdf update updates asdf itself.
• asdf list all <tool> lists upgrades but doesn't apply them.
• asdf latest <tool> shows the latest version. You may not want the very latest one though. For example, with Node.js, you may want the latest version under the 16.x branch.

Describe other workarounds you've considered

I think the only workaround is the manual approach, which is labor-intensive.

[jthegedus]

As a note: asdf latest <tool> <version> exists to filter specific versions. Eg: asdf latest nodejs 16 will give latest of the 16 releases.

As you state, this is easier to implement in tools that aren't Shell scripts.

I do not think interactive update is something we would consider adding to the core. This is something that would be ideal to implement as a user-land script. We are intending on adding a recipes/cookbook section to the documentation site. Feel free to share your Shell implementations here for others.

[timdp]

As a note: asdf latest <tool> <version> exists to filter specific versions. Eg: asdf latest nodejs 16 will give latest of the 16 releases.

I know, but part of interactive upgrades is having the option to upgrade to a higher major version.

As you state, this is easier to implement in tools that aren't Shell scripts.

I think that goes for most features of asdf, and most things in general, but I don't think that's a valid reason not to include it in asdf. 🙂

I think a user-friendly shell implementation would quickly end up relying on other tools or introducing a lot of boilerplate. For example, checkboxes a la Yarn would greatly improve usability, but are almost impossible to implement in pure Bash. (Yarn itself in fact also relies on Ink for this.)

[jthegedus]

I think a user-friendly shell implementation would quickly end up relying on other tools or introducing a lot of boilerplate. For example, checkboxes a la Yarn would greatly improve usability, but are almost impossible to implement in pure Bash. (Yarn itself in fact also relies on Ink for this.)

I agree, which is why this is likely going to be a "wont fix" issue as we are not able to stay on top of bug fixes and feature requests as is. The difficulty in implementation and maintenance far exceeds the usability increase of this feature.

In addition to that, the "bump" functionality of Yarn and other tools rely heavily on version ranges mechanisms, which we do not support. So how we implement this is not clear. The "to" versions are not easily determined in our ecosystem.

You state

part of interactive upgrades is having the option to upgrade to a higher major version

but the example from Yarn only shows bumping minor.patch due to the range from ^, so the bump command isn't giving the option to pick, latest minor.patch or latest major, the user has to do that beforehand when defining the range restrictions.

[timdp]

In addition to that, the "bump" functionality of Yarn and other tools rely heavily on version ranges mechanisms, which we do not support.

I'm totally with you on that, and I imagine it would be incredibly hard for plugins to model the specific versioning mechanism on a per-tool basis.

That said, in my experience, you often just want either the latest version that would be compatible if the tool used SemVer, or the latest version altogether. It's probably because I'm in the JS ecosystem, but I think this assumption might still hold in the majority of cases.

I've therefore also refactored asdf-bump to give you both options. Additionally, it's now nicely interactive, pretty much like Yarn. Here's how it looks:

I'm not expecting asdf to follow suit, but if anyone's looking for this feature, know that it's available from npm.

[ghostsquad]

I'm imagining next-gen asdf written in go in order to provide a lot more horsepower and less compatibility concerns stemming from shell scripts in general. This sounds like a really cool feature to have.