feat: Auto-install missing versions in asdf local.

[toothbrush]

Summary

I frequently want to be able to upgrade my .tool-versions straight to the newest version of a plugin with the asdf local command. At the moment, the first repository i perform this on, i'll get an error that the latest version isn't installed:

$ asdf local ruby latest
version 3.3.0 is not installed for ruby ❌

Instead of having to read the latest version from the error output, then type, e.g., asdf install ruby 3.3.0, then redo my command, i'd like to be able to have asdf local do the installation automatically. This will save me a tedious manual step.

With this change, i can do it all in one go:

$ echo "local_command_auto_install_missing_version = yes" >> .asdfrc
$ asdf local ruby latest
...installs Ruby 3.3.0...
$ cat .tool-versions
ruby 3.3.0 🎉

Other Information

Apologies for the PR spam. Hopefully this one will be acceptable. I previously misunderstood a few things about how asdf works under the hood – i think this is a better way to address what i actually wanted, namely less manual version swizzling 😁

Also, i'm happy to find a better name for the config option.

[feld]

The maintainer won't add automatic plugin installs because they're disillusioned into thinking this is a security threat, so this -- which is a logical extension of the idea -- is probably going to be rejected. So many of us have wanted this for years.

https://github.com/asdf-vm/asdf/issues/276

[HashNuke]

@feld The context for #216 and this issue are different. Issue-216 was auto-installing plugins. This one is for auto-installing the latest version if missing.

[toothbrush]

• Can we add appropriate tests for this change? The relevant file to do so would be test/version_commands.bats

• Can we please update this to use a command-line option instead of the configuration file?

Hey Akash, thanks for your response! Indeed i'm happy to add tests and a command-line flag if you prefer that approach. Before doing the work i think it'd be good to discuss the UX though.

My sense is that if we provide both --install-missing and a config file option, that caters to people who want lots of control, as well as people like me who decide they always want auto-installation of a latest version of a known plugin. If we have a CLI flag instead of the config file option, i believe we will not have improved the UX at all.

Consider, before the change:

$ asdf local ruby latest
version 3.3.0 is not installed for ruby ❌
# Ah, whoops, i guess 3.3.0 is released, i'll install it manually:
$ asdf install ruby 3.3.0
...installs Ruby 3.3.0...
# Rerun previous command:
$ asdf local ruby latest
...now it works, .tool-versions correctly updated 👍

If we add only a --install-missing flag:

$ asdf local ruby latest
version 3.3.0 is not installed for ruby ❌
# Ah, whoops, i guess 3.3.0 is released, i'll install it -- what was the flag again? 🤔
$ asdf local ruby latest --install-missing
...installs Ruby 3.3.0, .tool-versions correctly updated 👍

It's true that this is only 2 commands versus 3 separate actions before, but arguably (my personal view, i guess others may disagree) it will actually be harder to remember this --install-missing flag you have to type out only sometimes. Personally i'd probably not use it and just do the old-fashioned 3-command incantation instead.

Does my concern make sense? From my point of view there's not much value in adding only a CLI flag without support for setting it persistently in .asdfrc. I'd happily do the work to support both styles, though -- i think you're right that a CLI flag would be good to have. After all, if it's disabled-by-default and preserving current behaviour, that seems like we're maximally empowering users to make their own choice about auto-installation of latest versions.

I would prefer that the user clearly knows that they are forcing an install.

That's a good point. We could consider adding some output such as Latest ruby version is 3.3.0, which not installed. Installing now... in the case that the auto-install flag is set?