Provide a flag or configuration option to allow asdf install to continue when missing plugins are found in .tool-versions

[Stratus3D]

I think we should stop installing when a missing plugin is encountered. Some projects define plugins in the order they must be installed in, because certain plugins depend on others. Proceeding to install subsequent versions after a plugin is not found could cause problems.

This change breaks my workflow as I intentionally do not install all plugins on all my machines (depending on which I need). Is there any way to disable this feature (looking at the code I guess no) or make it so it can be disabled?

Originally posted by @cmur2 in #1033 (comment)

[Stratus3D]

There are a couple different ways we could solve this:

1. Add an configuration option to asdf's .asdfrc file (new behavior)
2. Add a flag to the asdf install command to allow it to exit with a status code of 0 when plugins are missing (new behavior)
3. Add a flag to the asdf install command to make it exit with a status code of 1 when plugins are missing (old behavior)

To me, options 2 and 3 seem like the best. Thoughts?

[threkk]

I am ok with both approaches. To be honest, it is a matter of deciding which one is the most common case (2 or 3) and make that one the default. Other option could be to make the default depend on the .asdfrc file.

[jthegedus]

This is one of the reasons I dislike the asdf install command. It is very unclear to me how it should work and how people expect it to work.

Thinking out loud.

As I understand, it was introduced so people could easily setup a project on their system with little effort. The notion of blocking on a plugin not existing is because you want to ensure you have all the tools for the project you're currently working on.

Global management of tools perhaps fits outside the initial asdf install philosophy. 🤔 Though, .tool-versions is a way to codify what tools you rely on, if you don't rely on them, then they shouldn't be in the .tool-versions file. If you have multiple systems with different $HOME/.tool-versions files, then use different .tool-versions files in your symlinked dotfiles for each system.

I feel that the per-project usability of asdf should always trump the global ($HOME) usage. I also dislike the options presented as they impact both per-project usage and global usage.

Perhaps, we treat the "global" ($HOME) config separately to other .tool-versions, whereby we have more loose rules for commands like asdf install. The downside of course is this is then hidden behaviour, which is also terrible.

Perhaps .asdfrc config that only effects the global .tool-versions? eg: skip_plugin_check_for_asdf_install_for_global_tool-versions? Again, this seems like a niche use case, a use case which (to me at least) goes against the purpose of the tool, and which has a userland solution.

[threkk]

Being honest, I dislike the idea of having different behaviours depending on the directory. That is inconsistent and hard to explain for newcomers. If someone decides to locate a project in the home directory (odd decision, but still a decision), that person would be wondering why it didn't work as expected. I would rather go for a solution where things behave consistently, but the behaviour can be changed.