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

feat: Auto-install missing versions in asdf local. #1714

Open
wants to merge 3 commits into
base: master
Choose a base branch
from

Conversation

toothbrush
Copy link
Contributor

@toothbrush toothbrush commented Jan 23, 2024

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.

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:

```shellsession
$ 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:

```shellsession
$ 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 🎉
```
@toothbrush toothbrush requested a review from a team as a code owner January 23, 2024 06:04
@feld
Copy link

feld commented Jan 26, 2024

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.

#276

@HashNuke
Copy link
Member

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

Copy link
Member

@HashNuke HashNuke left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Thank you for the PR. Notes below.

  • 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?
asdf local ruby latest --install-missing

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

I haven't tested the PR. I'll do that after the changes are done.

@toothbrush
Copy link
Contributor Author

toothbrush commented Jan 27, 2024

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

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

Successfully merging this pull request may close these issues.

3 participants