bug: asdf creates shim for command (ffmpeg) installed/managed via homebrew

[cobyism]

Describe the Bug

I have ffmpeg installed on my machine via homebrew. My use of ffmpeg is unlikely to ever require multiple versions on my machine, so I do not use the asdf plugin for ffmpeg, nor do I want to—the version from brew is fine.

Unfortunately, asdf creates a shim for the ffmpeg command, which results in the following output:

$ ffmpeg
No preset version installed for command ffmpeg
Please install a version by running one of the following:

asdf install python 3.11.2

or add one of the following versions in your config file at /Users/cobyism/.tool-versions
python miniconda3-latest

This causes other commands and processes expecting ffmpeg to be present to fail.

This is frustrating and surprising because ffmpeg is correctly installed on my machine via homebrew:

$ ls -l /opt/homebrew/bin/ffmpeg
lrwxr-xr-x 31 cobyism 16 Jun 14:26  /opt/homebrew/bin/ffmpeg -> ../Cellar/ffmpeg/6.0/bin/ffmpeg

$ /opt/homebrew/bin/ffmpeg -version
ffmpeg version 6.0 Copyright (c) 2000-2023 the FFmpeg developers
built with Apple clang version 14.0.3 (clang-1403.0.22.14.1)
configuration: …

I would like things I manage with asdf to be completely disjoint from things I do not manage with asdf. How can I ensure this is the case? Is there a way for me to tell asdf to completely ignore unrelated commands/concerns, or to skip/opt-out of shims for certain things?

Beyond this specific issue of a shim being created for ffmpeg, this raises a further question in my mind: why did asdf begin to care at all about an unrelated command/package? What else on my system might asdf be hijacking or creating shims for in a way I’m not aware of? Sure, I can inspect the shims directory myself, but… I’d really like to not have to do that.

When taken together with asdf somehow inserting itself into a git filter-branch command I opened an issue for recently (https://github.com/asdf-vm/asdf/issues/1588), there seems to be a theme here of asdf being involved in surprising ways with system-level commands I most definitely don’t want associated with asdf in any way.

Steps to Reproduce

1. Install ffmpeg via homebrew: brew install ffmpeg
2. Have asdf installed.
3. Run ffmpeg.
4. Behold.

Expected Behaviour

• I expect asdf to manage concerns relating to the asdf plugins I have installed.
• I expect expect asdf to not interfere with commands, binaries, aliases, or anything else that isn’t explicitly related to the version of a tool from a plugin. This includes commands like ffmpeg which I have choosen to install via homebrew.

Actual Behaviour

• asdf creates a shim for ffmpeg, despite this being entirely unrelated to the toolchains I manage with asdf.

Environment

OS:
Darwin [REDACTED] 23.0.0 Darwin Kernel Version 23.0.0: Fri Jun 30 17:48:57 PDT 2023; root:xnu-10002.0.168.505.3~1/RELEASE_ARM64_T8112 arm64

SHELL:
zsh 5.9 (x86_64-apple-darwin23.0)

BASH VERSION:
3.2.57(1)-release

ASDF VERSION:
v0.12.0

ASDF INTERNAL VARIABLES:
ASDF_DEFAULT_TOOL_VERSIONS_FILENAME=.tool-versions
ASDF_DATA_DIR=/Users/cobyism/.asdf
ASDF_DIR=/opt/homebrew/opt/asdf/libexec
ASDF_CONFIG_FILE=/Users/cobyism/.asdfrc

ASDF INSTALLED PLUGINS:
clojure
direnv
golang
haskell
nodejs
python
ruby

asdf plugins affected (if relevant)

No response

[cobyism]

From https://github.com/asdf-vm/asdf/issues/928:

We get a number of bug reports around the error No preset version installed for command <CMD> message.

There’s obviously many possible reasons for this as a recurring theme in issues when dealing with a system that relies on shims, and I’m not nearly familiar enough with the underlying mechanics of asdf to comment. From these two issues I’ve run into though (this one and https://github.com/asdf-vm/asdf/issues/1588), it really does just seem surprising/odd (at least to me) that asdf is involved at all in non-plugin related commands like git/ffmpeg/etc. If I were to uninstall asdf completely, those commands I have installed outside of asdf would all Just Work™ as expected. On the surface, this all feels like an opportunity to lean into the principle of least surprise.