asdf icon indicating copy to clipboard operation
asdf copied to clipboard

Can't detect latest version for plugins that use a "v"

Open particledecay opened this issue 3 years ago • 5 comments

Describe the bug

For plugins that list their versions with a leading "v", the latest command will return nothing by default. This means when you run plugin-test (such as in CI) against a plugin, it will always fail.

To Reproduce

Steps to reproduce the behavior:

  1. Add any plugin that produces a list of versions with a leading "v".
  2. Run asdf plugin-test <that_plugin>.

Expected behavior

The latest version will be displayed from the provided versions returned from the list-all command.

Actual behavior

Nothing is displayed.

Environment

❯ asdf info
OS:
Linux joebeast 5.10.4-051004-generic #202012301142 SMP Wed Dec 30 11:44:55 UTC 2020 x86_64 x86_64 x86_64 GNU/Linux

SHELL:
fish, version 3.1.0

ASDF VERSION:
v0.8.0-f55fca4

ASDF ENVIRONMENT VARIABLES:


ASDF INSTALLED PLUGINS:
helm                         [email protected]:Antiarchitect/asdf-helm.git
kconf                        [email protected]:particledecay/asdf-kconf.git
kubectl                      [email protected]:Banno/asdf-kubectl.git
terraform                    [email protected]:Banno/asdf-hashicorp.git

asdf plugins affected (if relevant):

Screenshots Selection_014

Additional context I think there are a few options:

  1. Update the docs to require that versions follow Semantic Versioning (since "v" isn't SemVer and you can better control for parsing versions). Although not every plugin is easy to translate from non-SemVer to SemVer.
  2. Add a v? to the regex for the plugin-test command.
  3. Defer latest version detection to the plugin (or at least allow it to be overridden with bin/latest or bin/latest-stable or something).

particledecay avatar Jan 12 '21 20:01 particledecay

Can confirm for helm and kubectl as well as direnv and k6.

For now, @particledecay's option 2 would be most expedient for an immediate fix, but it would be nice to see some discussion around handling version numbers more robustly to prevent this kind of issue in the future.

I'm not sure exactly what that would look like, as I'm not confident there's some universal versioning scheme that will work for all plugins (e.g. as @particledecay pointed out, cases where a tool doesn't follow SemVer). But I feel like a more robust solution would be nice.

clmay avatar Jan 28 '21 06:01 clmay

I also have this problem with azctx / asdf-azctx.

For now, I used --asdf-tool-version v0.2 to workaround this issue, but it would be great to see this fixed :wink:

janpieper avatar Feb 19 '21 09:02 janpieper

I worked around this for now in my asdf plugins by simply removing the "v" for tools that I know include it: https://github.com/particledecay/asdf-kconf/blob/master/bin/list-all#L20

particledecay avatar Feb 21 '21 06:02 particledecay

Was not aware of --asdf-tool-version thanks @janpieper!

clmay avatar Mar 01 '21 20:03 clmay

#763 (OPs 3rd suggestion) is the direction we want to take to resolve this.

jthegedus avatar Apr 27 '21 07:04 jthegedus

I believe this was resolved in #938 which added bin/latest-stable to the plugin API as the command called from asdf latest <plugin> with filtering asdf latest nodejs 16 gets the latest for [email protected].

jthegedus avatar Jan 13 '23 14:01 jthegedus