Allow suppression of error when no version of a tool is configured

[gareth]

Is your feature request related to a problem? Please describe

I work on multiple projects with different versions of tools - the kind of use case that asdf is great at managing.

I'd like to display the active versions of tools in my prompt. The script would involve some variation of the following:

$ active_versions=("${(@f)$(asdf current 2> /dev/null | awk '{ print $1 ":" $2 }')}")

$ echo $active_versions
elm:0.19.1 nodejs:14.15.4 ruby:2.6.6

Outside of a project folder I don't need access to e.g. nodejs or elm (or even ruby to be honest). However, not having a version configured for the current folder (e.g. in a parent folder or ~/.tool-versions) leads to an error displayed after every command:

$ true
No version set for command ruby
Consider adding one of the following versions in your config file at
ruby 2.6.6
No version set for command node
Consider adding one of the following versions in your config file at
nodejs 14.15.4

$ 

For some tools I can mitigate this: I can use asdf global ruby system to remove that warning from the toolchain. However for other tools with no system install (like nodejs) this approach doesn't work.

Describe the proposed solution

I would like some way to indicate (maybe at a global level, maybe per-tool) that the lack of a configured tool is not an error that needs to be alerted after every shell command.

Attempting to use an unconfigured tool can still fail the way it already does.

Describe similar asdf features and why they are not sufficient

The warning appears to be generated unconditionally by the asdf shell integration, and that's unavoidable and (to me) undesirable.

The aim is for my prompt in a project folder to only include versions of tools used by the project. Setting a global version of every plugin on my system means they all get reported by asdf current and it's impossible to extract just the tools relevant to the current project for the prompt.

Describe other workarounds you've considered

I can mitigate this slightly by setting a system version of certain tools and altering my command to look like:

asdf current 2> /dev/null | awk '{ if ($2 != "system") print $1 ":" $2 }'

but as mentioned above that only works for tools that can have a system value set.

[jthegedus]

Thanks for taking the time to be thorough. This is partially related to #928

Outside of a project folder I don't need access to e.g. nodejs or elm (or even ruby to be honest). However, not having a version configured for the current folder (e.g. in a parent folder or ~/.tool-versions) leads to an error displayed after every command:

$ true
No version set for command ruby
Consider adding one of the following versions in your config file at
ruby 2.6.6
No version set for command node
Consider adding one of the following versions in your config file at
nodejs 14.15.4

$ 

This only happens when executing a tool asdf has a shim for. So in this instance, a shim was created for true by a tool installed via ruby 2.6.6 or nodejs 14.15.4. Likely installed via gem or npm. asdf does not shadow all commands, only those which a shim was created.

There are two solutions to this issue:

1. set system as a global fallback so when this resolution fails it knows to pass through to the system
2. uninstall the tool that created the shim. IE: if it was added with gem install then run gem uninstall followed by asdf reshim ruby.

---

I'd like to display the active versions of tools in my prompt

we could add filters to asdf current, say --set & --unset, however the desire for such a command is very low (you're the first to ask) and there seems to be little value gained especially when you could add this to your own Shell aliases. May you describe further as to why this is feature is important?

Also, we may add things like this to a recipes page in our docs after we launch an overhaul.

[gareth]

Thanks for the great quick reply James.

This only happens when executing a tool asdf has a shim for. So in this instance, a shim was created for true by a tool installed via ruby 2.6.6 or nodejs 14.15.4.

The trouble I was having was that I was seeing this error output even when no command was being run, i.e. for every prompt in my shell.

From what you say here, I realise that it's probably because these shims (ruby and node) are being run implicitly by something in my prompt or other shell integration. The noisiness I'm annoyed by isn't asdfs default behaviour, but my own fault. I should have realised this sooner/had more faith!

I'll check this shortly and probably close the issue

[jthegedus]

I realise that it's probably because these shims (ruby and node) are being run implicitly by something in my prompt or other shell integration

Ah yes, that is the same scenario we discovered in #950. This can be very tricky when using asdf managed tools to setup your system config. This type of scenario should be in an FAQ.

These scenarios is why my distaste for the Python ecosystem which rely on a global unchanging runtime has grown over the past few years. The convenience of pip and npm as distributions platforms has normalized the usage of scripts with runtimes over compiled binaries. I personally opt for my shell/system setup to use git or binaries to install their deps, then use asdf for dev environment dep management.

[gareth]

As I suspected the logged lines were caused by a function in my own profile startup code. (Ironically it was a function I created while I was trying to write an earlier version of the same script, to load the current active versions into variables 🤦🏻‍♂️).

After removing those lines my shell is noiseless again 🎉

I still think there's a use case for me to be able to get the "closest" configured tools, ignoring any grandparent configuration. That gives me the option to answer the question "What tools does this project (at least claim to) use?".

I could do this by manually scanning for the closest .tool-versions file but that gets trickier if I'm using legacy_version_file = yes for projects where I'm collaborating with people not using asdf.

[gareth]

I'm closing this issue because my original premise was invalid.

If you agree that there might be scope for some way to find the "closest" set of configured tools then I'll create a separate issue for that - I realise it's not as simple a suggestion as I first made it seem.

[jthegedus]

I am glad you resolved your shell prompt issues.

If you agree that there might be scope for some way to find the "closest" set of configured tools then I'll create a separate issue for that - I realise it's not as simple a suggestion as I first made it seem.

Please do open an issue. It may stay open for a long time, but that gives others a chance to 👍 the issue and gives us an idea if the effort to implement and maintain is worth it.

If you can provide a code snippet along with that which filters the asfd current results then at worst we can add that to a future "recipes" docs page.

[Stratus3D]

@gareth here is are two one-liners that I think should do what you want, now that you've figured out what was producing those error messages.

Assuming pwd is your project root containing your project-specific .tool-versions file:

$ asdf current 2> /dev/null | grep "$(pwd)" | awk '{ print $1 ":" $2 }'

Assuming the root of the Git repository is your project root :

$ asdf current 2> /dev/null | grep "$(git rev-parse --show-toplevel)" | awk '{ print $1 ":" $2 }'

Basically you can just grep asdf current for your project directory as each version line contains the path to the .tool-versions file that set it.