asdf

asdf copied to clipboard

Is your feature request related to a problem? Please describe.

I had an issue where my app wouldn't build correctly in CI because a plugin that was listed in .tool-versions hadn't been previously installed as a plugin. In this case it was pretty clear what the issue was because I got a No such file or directory error for the command (though the reason wasn't super clear, since it was part of migrating to GitHub actions and I thought that while I had installed it one step, maybe the state didn't carry over to the next step or something; took me a while to realize that asdf silently ignores unknown plug-ins). However, I can imagine a much more insidious version of this problem where, say python 3.7 is ignored and it falls back to system python or something like that.

Describe the solution you'd like

I would like a flag to asdf install, perhaps --expect-plugins, that would cause the command to exit with a failure status code if it detects a plugin in .tool-versions (I think, any .tool-versions in the ancestor chain, but maybe just the current directory?) that hasn't previously been added. That would have made my CI issue immediately apparent.

At work, we've standardized across teams on asdf among our dozens of apps, and it's second nature to do asdf install when working on a new project. So I'd probably use this flag by default all the time, just so I know right away if some team's project introduces a new plugin.

Describe similar asdf features and why they are not sufficient

I've found a number of issues related to unknown plugins in .tool-versions. Most propose some version of automatically installing those plugins. While I personally would prefer that solution, I know that it's been rejected. However, I haven't found my specific proposal here in any other issues, and I think it might be acceptable where the others weren't.

Describe workarounds you've considered

I suppose a shell script that I can alias asdf install to.

Additional context

If this solution is acceptable, I'd be happy to work on a PR for it.

asdf install in the GitHub Action is completely different to asdf install on you local machine. This is cause for confusion and I would like to dial back the GitHub Action so it is inline with the local machine asdf people are used to.

asdf install in the GitHub Action actually installs plugins in .tool-versions if they use the same shortname as those in the asdf-plugin repo.

The --expect-plugins flag you propose, while useful, should probably be the default behaviour. If .tool-versions has a plugin name that is not in asdf plugin list, then running asdf install should at least warn the user there is a missing plugin for shortname=X in file .tool-versions

Whether the GitHub Action immediately inherits this behaviour when added to this core I do not know, so the issue may persist in CI and not help your original issue. I wish to rewrite the Actions to align with the core, but alas, so much to do.

If .tool-versions has a plugin name that is not in asdf plugin list, then running asdf install should at least warn the user there is a missing plugin for shortname=X in file .tool-versions

Hmmm I actually came here to propose the opposite, namely that $ asdf install should install all the plugins and versions listed in .tool-versions. (Meanwhile, it should obviously warn the user about plugins and versions that don't exist / cannot be installed.) The reason is that if I have a project that uses N tools with N ≫1, I don't want to have to run asdf plugin add X for every single one of those N plugins before finally being able to run asdf install. Instead, asdf should simply look at .tool-versions to figure out which plugins to use. (Caveat: One might have to think about what to do about non-standard plugins that users install via asdf plugin add <name> <git-url>.)

While I appreciated the work into making asdf install more predictable by warn missing plugins and exit out the process.

I would like to keep the previous behavior though. A --partial flag that would just simply warn any missing plugins but install the rest of the plugins would be suffice.

Normally I would store my .tool-versions in a single place for all the machines I'm using (whether it work or personal one). Then in each of those machine, I would just have plugins I need for those particular machine. This would simplify my setup as I don't have to manage multiple version of .tool-versions for different purposes.