Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

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

matthijsqd opened this issue Nov 2, 2021 · 6 comments · Fixed by #1238


Copy link

matthijsqd commented Nov 2, 2021

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
  1. Create a .tool-versions-foobar file in the home directory.
erlang ref:master
elixir 1.12.3-otp-24
golang 1.17.2
  1. export ASDF_DEFAULT_TOOL_VERSIONS_FILENAME='.tool-versions-foobar'
  2. 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>"


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

zsh 5.8 (x86_64-apple-darwin21.0)



elixir                       ssh://
erlang                       ssh://
golang                       ssh://
nodejs                       ssh://
rust                         ssh://

asdf plugins affected (if relevant)

No response

@matthijsqd matthijsqd added the bug label Nov 2, 2021
Copy link

Stratus3D commented Nov 12, 2021

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

@Stratus3D Stratus3D added this to the v0.9.1 milestone Dec 3, 2021
Copy link

emcd commented Dec 27, 2021

Just ran into this too. Looks like it would not be too hard to fix. A move from to before (Or equivalent lines on HEAD.) However, the description of the second test at 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.)

Copy link

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

Copy link

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

if [ "$cmd" = "global" ]; then
elif [ "$cmd" = "local-tree" ]; then
else # cmd = local
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.

Copy link

@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 added a commit that referenced this issue May 27, 2022
… present (#1238)

* fix: always use ASDF_DEFAULT_TOOL_VERSIONS_FILENAME for filename when present
* fix: correct version command unit tests for ASDF_DEFAULT_TOOL_VERSIONS_FILENAME

Fixes #1082
Copy link

@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).

petertriho added a commit to petertriho/dotfiles that referenced this issue Jun 10, 2022
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
None yet

Successfully merging a pull request may close this issue.

4 participants