Open toothbrush opened 5 months ago
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.
@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.
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?
Summary
I frequently want to be able to upgrade my
.tool-versions
straight to the newest version of a plugin with theasdf local
command. At the moment, the first repository i perform this on, i'll get an error that the latest version isn't installed: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 haveasdf local
do the installation automatically. This will save me a tedious manual step.With this change, i can do it all in one go:
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.