Open XaF opened 1 year ago
Related to #1314
This is already happening to me:
When no global or local is set, before showing the No version is set for command for a shim, asdf should look through the path if such command, outside of the asdf path, does exist, and if such, default to using it.
If there is a shim with the same name as a binary in the system's PATH
, asdf
will call the system's one before complaining.
For example, say you have Graphviz's dot
binary in your system. When using the golang
plugin, if you install a package exposing a binary called dot
, then asdf
sets up a shim for that. From that moment on, when you try to call dot
, it will always be managed by asdf
as a shim. That is:
golang
has a binary called dot
, that one will be called. E.g. ~/.asdf/installs/golang/1.21.5/packages/bin/dot
golang
has not any binary called dot
, then:
dot
exists in the system's PATH
, then that's the one being used. /usr/bin/dot
in my case.dot
in system's PATH
you get the message: No version is set for command dot
.
Is your feature request related to a problem? Please describe
Using tools such as
rbenv
andgoenv
are not making things incompatible with system versions of the softwares. This means that if I'm in a directory with a.ruby-version
or.go-version
, the specified version is going to be used. But if outside such directory tree, and if a global version is not set, but I do have a system version of the tool, then that system version is going to be used.That means that using
rbenv
orgoenv
are not forcing me to set a global version to keep using my tools outside of locally-defined versions, they "just work".asdf
does not, showing the following message:Describe the proposed solution
When no global or local is set, before showing the
No version is set for command
for a shim, asdf should look through the path if such command, outside of the asdf path, does exist, and if such, default to using it.asdf current
could maybe also showsystem
when using the system version of a tool.Describe similar
asdf
features and why they are not sufficientThe only alternative is setting a global version (
asdf global <tool> system
) This still requires a manual operation, while this should be the default operation.Describe other workarounds you've considered
Using other tools than
asdf
such asgoenv
,rbenv
,pyenv
, that do not allow to centralize all that logic into a single tool... but do allow support for the system version of the tools. I do believeasdf
would benefit from that change.