bug: asdf uses .tool-versions instead of configured ASDF_DEFAULT_TOOL_VERSIONS_FILENAME

[matthijsqd]

Describe the Bug

When the environment variable ASDF_DEFAULT_TOOL_VERSIONS_FILENAME is set to e.g. .tool-versions-foobar, but there is still a .tool-versions file present, asdf used the .tool-versions file instead of the configured name. When the .tool-versions file is removed, the correct file is used.

I expected the configured name to take precedence, particularly because the documentation states: "Typically you should not override the default value unless you know you want asdf to ignore .tool-versions files".

Steps to Reproduce

1. Create a .tool-versions file in the home directory:

erlang 24.0.6
elixir 1.12.3-otp-24
golang 1.17.2

2. Create a .tool-versions-foobar file in the home directory.

erlang ref:master
elixir 1.12.3-otp-24
golang 1.17.2

3. export ASDF_DEFAULT_TOOL_VERSIONS_FILENAME='.tool-versions-foobar'
4. run asdf current

Expected Behaviour

elixir          1.12.3-otp-24   /$HOME/.tool-versions-foobar
erlang          ref:master      /$HOME/.tool-versions-foobar
golang          1.17.2          /$HOME/.tool-versions-foobar
nodejs          ______          No version set. Run "asdf <global|shell|local> nodejs <version>"
rust            ______          No version set. Run "asdf <global|shell|local> rust <version>"

Actual Behaviour

elixir          1.12.3-otp-24   /$HOME/.tool-versions
erlang          24.0.6          /$HOME/.tool-versions
golang          1.17.2          /$HOME/.tool-versions
nodejs          ______          No version set. Run "asdf <global|shell|local> nodejs <version>"
rust            ______          No version set. Run "asdf <global|shell|local> rust <version>"

Environment

OS:
Darwin ***** 21.1.0 Darwin Kernel Version 21.1.0: Wed Oct 13 17:33:01 PDT 2021; root:xnu-8019.41.5~1/RELEASE_ARM64_T6000 arm64

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

ASDF VERSION:
v0.8.1

ASDF ENVIRONMENT VARIABLES:
ASDF_DIR=/opt/homebrew/Cellar/asdf/0.8.1_1/libexec
ASDF_DEFAULT_TOOL_VERSIONS_FILENAME=.tool-versions-foobar

ASDF INSTALLED PLUGINS:
elixir                       ssh://git@github.com/asdf-vm/asdf-elixir.git
erlang                       ssh://git@github.com/asdf-vm/asdf-erlang.git
golang                       ssh://git@github.com/kennyp/asdf-golang.git
nodejs                       ssh://git@github.com/asdf-vm/asdf-nodejs.git
rust                         ssh://git@github.com/asdf-community/asdf-rust.git

asdf plugins affected (if relevant)

No response

[Stratus3D]

I confirmed this is a problem on my machine. PR to fix is welcome.

[emcd]

Just ran into this too. Looks like it would not be too hard to fix. A move from https://github.com/asdf-vm/asdf/blob/v0.9.0/lib/utils.bash#L215-L221 to before https://github.com/asdf-vm/asdf/blob/v0.9.0/lib/utils.bash#L192. (Or equivalent lines on HEAD.) However, the description of the second test at https://github.com/asdf-vm/asdf/blob/v0.9.0/test/utils.bats#L214-L232 has me wondering if there is maybe some deeper intentional behavior here.

That said, in the process of looking into this, I found a workaround superior solution to my problem: the use of a plugin-specific environment variable. In my case, using ASDF_PYTHON_VERSION actually gives me simpler override behavior than generating a .tool-versions-override with sed and pointing ASDF_DEFAULT_TOOL_VERSIONS_FILENAME at it. @matthijsqd : Did you look at ASDF_ERLANG_VERSION for your case? (No idea if it will work within the constraints of your problem space, but throwing it out there, just in case.)

[matthijsqd]

@emcd Indeed, I have been able to work around this using the ASDF_ERLANG_VERSION variable.

[squaresurf]

@Stratus3D is ASDF_DEFAULT_TOOL_VERSIONS_FILENAME only expected to work with global commands? When looking at

asdf/lib/commands/version_commands.bash

Lines 20 to 26 in 853eede

	if [ "$cmd" = "global" ]; then
	file=${ASDF_DEFAULT_TOOL_VERSIONS_FILENAME:-$HOME/.tool-versions}
	elif [ "$cmd" = "local-tree" ]; then
	file=$(find_tool_versions)
	else # cmd = local
	file="$(pwd)/.tool-versions"
	fi

If the env var should only work with the global file, then I'll open a PR to make that clear in the docs, otherwise I can work on fixing this and update it to work across the whole system.

[Stratus3D]

@squaresurf good observation. I'm not certain what the intent was there with that code. If you're using asdf local <tool> <version> or asdf global <tool> <version> both should either work or not work with ASDF_DEFAULT_TOOL_VERSIONS_FILENAME. That does appear to be a bug, however not the one reported by the original issue here.

[Stratus3D]

@matthijsqd @squaresurf the issues both of you reported should be fixed now on latest master. If you want to test it upgrade with asdf update --head. A new patch version will be tagged soon (within a month).