Previously, if we ran a command like `asdf install` and we encountered a
plugin that didn't exist, asdf produces an error saying "No such
plugin". Without knowing which plugin it could be referring too, we'd
have to manually go through each plugin in `.tool-versions` to find the
culprit.
With this commit, we'll now also include the plugin name as part of the
messaging for easier debugging.
Instead of just looking in $HOME/.tool-versions, allow the default
tool-versions file location to be specified through the variable
$ASDF_TOOL_VERSIONS.
Noticed we had some duplicated logic for finding the
plugins installation path. This caused the bug described
by #213 where the installation command and the find_executable_path
were using different paths.
Fixes#213
Before this patch, with a `.tool-versions` file like:
```
lfe ref:master
```
`get_preset_version_for` would return `ref` instead of `ref:master`.
Same was happening for `path:` versions. Actually there was PR #95
on which I based my changes but instead of using space as delimiter
I went for using `|` which would be a lot more weird if present as
part of a file path, this also allows to specify paths which have
spaces which are much more frequent.
Closes#94#95
For example if asdf finds that the `ASDF_FOO_VERSION` is
defined in the current environment it will override the
version of `foo` from the `.tool-version` file.
Closes#49
Without this patch, asft was not able to determine the tool version
for a project located outside the user's HOME directory.
```
/work/project/
/home/me/.tool-versions
```
This changeset lets asdf find the global version stored at
$HOME/.tool-versions when the directory traversal from
the project dir was not able to find a suitable version.
