Previously, the shims directory was only excluded for system versions,
which meant that `asdf exec` would fall back to a shim if the install
didn't have the desired binary. If the shims are up to date this isn't a
problem since we check the metadata, but it causes issues if those are
out of sync for whatever reason.
I've checked all the uses of this function and I'm not seeing anywhere
we should need the old behavior.
It's possible for plugins to define new asdf commands. This way plugins can extend asdf capabilities or expose utilities related to their managed tool.
For example, a `foo` plugin might expose the command `asdf foo bar` by providing an executable file at `bin/bar`.
If `bin/bar` is a file but has no executable bit set, then its considered a source-able bash script, and will be sourced
with all the functions in `$ASDF_DIR/lib/utils.sh` already loaded.
A good example of this feature is the `nodejs` plugin, where people must import the release team keyring before
installing a nodejs version. People can execute the following command without having to know where exactly is the plugin located.
- remove test for install command edge case from parsing tool-versions (no longer relevant)
- add test for install command honoring legacy version files
- clean up test names to differentiate between installing a single version vs all dependencies
The current behavior in shims is to check if there's an existing shim for
which the shim we're currently checking is a prefix. For example, if the shim
has
# asdf-plugin: erlang 21.2.6
Then adding a shim for `erlang 21.2` will fail.
This updates the `grep` check to match the end of the line as well so we
always get a full version check.
Fixes#517
With the previous version, the following case would fail.
It would use python 2.7.15 when running pip
instead of version 3.7.2.
Shim for `pip`
```bash
exec /home/daniel/.asdf/bin/asdf exec "pip" "$@"
```
`.tool-versions`:
```
python 3.7.2 2.7.15 system
```
Add a "shell" command similar to the existing "global" and "local"
commands, which sets the version in an environment variable instead of
writing it to a file. This was inspired by the similar functionality in
rbenv.
It works by adding a wrapper function for the asdf command. It forwards
to a "sh-shell" command that returns the exports as shell code which is
then evaled by the wrapper. This is a little gross, but we need to run
the code in the shell context in order to set variables.
Resolves#378
- Make shim-exec, shim-env, and which use the same logic to look for commands
- Make sure shim-exec and which use a plugin exec-path hook as documented
(the hook takes a relative path to the executable and returns also
a relative path, possibly modified)
- Fix shellchecks
Suppose a `foo` plugin is installed and provides a `bar` executable.
The following hooks will be executed when set in `.asdfrc`:
```shell
post_asdf_install_foo = echo installed foo version ${1}
post_asdf_reshim_foo = echo reshimmed foo version ${1}
pre_foo_bar = echo about to execute command bar from foo with args: ${@}
post_foo_bar = echo just executed command bar from foo with args: ${@}
```
Features
* New shim version meta-data allows shims to not depend on a particular plugin
nor on its relative executable path (#431)
Upgrading requires shim re-generation and should happen automatically
by `asdf-exec`:
`rm -rf ~/.asdf/shims/` followed by `asdf reshim`
* Added lots of tests for shim execution.
We now make sure that shim execution obeys plugins hooks like
`list-bin-paths` and `exec-path`.
* Shim exec is now performed by a new `bin/private/asdf-tool-exec` that might
be faster for most common use case: (versions on local .tool-versions file)
but fallbacks to slower `get_preset_version_for` which takes legacy formats
into account.
* Shim exec recommends which plugins or versions to set when command is
not found.
Fixed Bugs
* Allow many plugins to provide shims with same executable name (#431)
Previous implementation exits abruptly when no version is installed for
a plugin. This prevented the list command from listing the versions for
some other plugins.
This commit allows list command to continue executing even when no
version is installed for some plugins.
Example, plugin a with 1.0, b with none, and c with 2.0.
Previous implementation:
```
$ asdf list
a
1.0
b
No versions installed
```
After commit changes:
```
$ asdf list
a
1.0
b
No versions installed
c
2.0
```
When checking if a plugin is installed (to display a flag) it is not
necessary to loop through all installed plugins, since we already have
a name we can check directly.
Also expand test case to test this code path too.
It seems to have been lost in 88d47bbd69.
Probably by accident?
I also pulled the literal bits into the format string. It looks more
readable to me that way. I'm happy to remove that if it's not desired.
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
latest tag from the list of sorted tags.
The setup code for these tests isn't ideal. It would be nice not to have
to worry about the remote. Without the 'origin' remote set the Travis
build would fail though.
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
- Remove plugin shims when last version is uninstalled.
- Remove shims on plugin-remove
When the latest version of a tool is uninstalled,
Remove the plugin shims (marked with metadata at #122)
Also found lots of missing tests and added them.
Closes#67
When a shim is created, add plugin metadata so we can later know which shims belong to which plugins, this will help aid with removing unused shims on uninstall. See #67
```
# asdf-plugin: ${plugin_name}”
```
Thanks to @duijf for the metadata proposal.
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.
* Rename `asdf which` -> `asdf current`
* Output `set by $path` with current command
* Use dummy plugin in current_command test
* Hide "set by" message if derived from legacy file
