bug: asdf global is broken after 711ad99: No such file or directory

[laggardkernel]

Describe the Bug

asdf global neovim 0.7.2 breaks on one of my machine, but works well on another one. The problem may be related with my /home directory, which is symlinked to /data/home. Both of my machines have this symlink setup. Tested with current latest commit a75f851

❯ asdf global neovim 0.7.2
/home/<username>/.local/share/asdf/lib/functions/versions.bash: line 67: /home/<username>//home/<username>/.local/share/asdf/installs/versions: No such file or directory

After some debugging with git bisect, I found the problem related with commit 711ad99

❯ git bisect good
711ad991043a1980fa264098f29e78f2ecafd610 is the first bad commit
commit 711ad991043a1980fa264098f29e78f2ecafd610
Author: Trevor Brown <Stratus3D@users.noreply.github.com>
Date:   Fri May 27 07:50:04 2022 -0400

    fix: always use ASDF_DEFAULT_TOOL_VERSIONS_FILENAME for filename when 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

 lib/functions/versions.bash |  8 ++++++--
 lib/utils.bash              | 12 +++++++++---
 test/version_commands.bats  | 28 ++++++++++++++++++++++++----
 3 files changed, 39 insertions(+), 9 deletions(-)

Steps to Reproduce

Make /home a symlink to /data/home. And try

❯ asdf global neovim 0.7.2
/home/<username>/.local/share/asdf/lib/functions/versions.bash: line 67: /home/<username>//home/<username>/.local/share/asdf/installs/versions: No such file or directory

Expected Behaviour

asdf global works.

Actual Behaviour

asdf global is broken.

Environment

❯ asdf info
OS:
Linux theoden 5.10.27-gentoo #3 SMP Tue Jul 20 11:49:22 CST 2021 x86_64 AMD EPYC 7K62 48-Core Processor AuthenticAMD GNU/Linux

SHELL:
GNU bash, version 5.1.8(1)-release (x86_64-pc-linux-gnu)
Copyright (C) 2020 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later <http://gnu.org/licenses/gpl.html>

This is free software; you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law.

ASDF VERSION:
v0.10.2-a75f851

ASDF ENVIRONMENT VARIABLES:
ASDF_DEFAULT_TOOL_VERSIONS_FILENAME=/home/<username>/.local/share/asdf/installs/versions
ASDF_DATA_DIR=/home/<username>/.local/share/asdf
ASDF_DIR=/home/<username>/.local/share/asdf
ASDF_CONFIG_FILE=/home/<username>/.config/asdf/config

ASDF INSTALLED PLUGINS:
java                         https://github.com/halcyon/asdf-java.git master 460d8f7
neovim                       https://github.com/richin13/asdf-neovim.git master 1fb2f66
nodejs                       https://github.com/asdf-vm/asdf-nodejs.git master b2d06a7
ruby                         https://github.com/asdf-vm/asdf-ruby.git master d37b3e

### asdf plugins affected (if relevant)

`asdf` `neovim`

[jthegedus]

Quoting #1301 (comment)

---

This isn't a bug. Setting ASDF_DEFAULT_TOOL_VERSIONS_FILENAME is meant to be filename change, not full file path change as you show in your example.

Global .tool-versions is not special from local except it is always $HOME/.tool-versions. Setting ASDF_DEFAULT_TOOL_VERSIONS_FILENAME just changes this to: $HOME/$ASDF_DEFAULT_TOOL_VERSIONS_FILENAME.

From the docs:

ASDF_DEFAULT_TOOL_VERSIONS_FILENAME - The filename of the file storing the tool names and versions. Defaults to .tool-versions. Can be any valid filename. Typically you should not override the default value unless you know you want asdf to ignore .tool-versions files.

asfd global<name> <version> will always try to write to $HOME/$ASDF_DEFAULT_TOOL_VERSIONS_FILENAME.

The reason for this is that versions are resolved by walking up the directory tree from the current, and $HOME is likely in that PATH.

#1295 may change this, but it is different from ASDF_DEFAULT_TOOL_VERSIONS_FILENAME

---

@Stratus3D perhaps we should include some validation of ASDF_DEFAULT_TOOL_VERSIONS_FILENAME to error when it contains path separators.

@laggardkernel To be clear, this is confusing behaviour. It was introduced in the infancy of the project and resolving, as proposed in #1295, is going to be breaking and require a change to the resolution algorithm to consider a true global version file outside of the walk-up the directory. #1238 was fixing a logic error which may masked the error you're now seeing.

[Stratus3D]

@jthegedus I have created #1309 for that. I think it will be a nice improvement that will hopefully reduce the number of config-related issues we have to deal with.

[laggardkernel]

Sorry to bother you guys, I didn't read it carefully enough to get this is a breaking change. Thanks for your help.