bug: python installation fails if make is also present in .tool-versions

[Kristonitas]

Describe the Bug

python installation fails if make is also present in .tool-versions

Steps to Reproduce

1. install asdf
2. asdf plugin add make
3. asdf plugin add python
4. echo "make 4.3\npython 3.8.13" > .tool-versions
5. asdf install

Expected Behaviour

I don't really know. In theory, installation of python depends on the environment, since its compiled from source (using various libraries). So maybe installing plugins should avoid using asdf shims, but that would mean that there would be make in the system, as well as one installed by asdf.

My workaround was to make the local plugin list global: cp .tool-versions, ~/.tool-versions. Of course, this should be done only in temporary build environments (github actions for example)

Actual Behaviour

python installation fails

// ...
No version is set for command make
Consider adding one of the following versions in your config file at 
make 4.3

Environment

OS:
Darwin KS-MB-AGAIN 21.5.0 Darwin Kernel Version 21.5.0: Tue Apr 26 21:08:37 PDT 2022; root:xnu-8020.121.3~4/RELEASE_ARM64_T6000 arm64

SHELL:
zsh 5.8.1 (x86_64-apple-darwin21.0)

ASDF VERSION:
v0.10.0

ASDF ENVIRONMENT VARIABLES:
ASDF_DIR=/opt/homebrew/opt/asdf/libexec

ASDF INSTALLED PLUGINS:
make                         https://github.com/yacchi/asdf-make.git main c8faf82
python                       https://github.com/danhper/asdf-python.git master 57a4d72

asdf plugins affected (if relevant)

python

[elliotcm]

I'm encountering this same issue when installing ruby:

% asdf install
az 2.36.0 is already installed
cf 8.4.0 is already installed
jq 1.6 is already installed
make 4.2.1 is already installed
nodejs 16.13.0 is already installed
To follow progress, use 'tail -f /var/folders/6b/5rvkmy5x3c70y6r664wdtpsmscq3f_/T/ruby-build.20220921102945.83422.log' or pass --verbose
Downloading openssl-3.0.5.tar.gz...
-> https://dqw8nmjcqpjn7.cloudfront.net/aa7d8d9bef71ad6525c55ba11e5f4397889ce49c2c9349dcea6d3e4f0b024a7a
Installing openssl-3.0.5...

BUILD FAILED (macOS 12.6 using ruby-build 20220910.1)

Inspect or clean up the working tree at /var/folders/6b/5rvkmy5x3c70y6r664wdtpsmscq3f_/T/ruby-build.20220921102945.83422.vdq0dj
Results logged to /var/folders/6b/5rvkmy5x3c70y6r664wdtpsmscq3f_/T/ruby-build.20220921102945.83422.log

Last 10 log lines:
***                                                                ***
***       perl configdata.pm --dump                                ***
***                                                                ***
***   (If you are new to OpenSSL, you might want to consult the    ***
***   'Troubleshooting' section in the INSTALL.md file first)      ***
***                                                                ***
**********************************************************************
No version is set for command make
Consider adding one of the following versions in your config file at 
make 4.2.1

[jthegedus]

Suggested solution

Setting an asdf global to fallback to the system make version is the appropriate solution here.

https://asdf-vm.com/manage/versions.html#fallback-to-system-version

Why does this happen

asdf resolves which version to use by climbing the directory tree from current dir to the root.

When it is in a random directory installing your tool, it tries to resolve which make version to use. So, from whatever dir it is actively in (it seems /var/... in your case @elliotcm ), it climbs to the root, doesn't find a version in a .tool-versions file and so errors.

The error tries to be helpful and looks at the plugin for the tool (make), and lists the versions already installed on the machine and suggests that you add a config for that version in the current dir.

Other comments

Tools installed via runtime languages like Nodejs, Ruby etc that depend on system dependencies are problematic for all version manager tools. If you also happen to manage those system tools with asdf, a fallback should be set to the system with https://asdf-vm.com/manage/versions.html#fallback-to-system-version

This isn't a bug, so much as asdf not owning the entire installation process.