fix: support latest with filter on local and global

[klane]

Summary

This PR extends the feature added in #575 to asdf global and asdf local. Users can now specify the global or local version of a tool as the latest installed version.

asdf global python latest
asdf local python latest
asdf local python latest:3.7

It also adds the ability to filter installed versions with asdf list:

# only list installed versions of Python 3.7
asdf list python 3.7

[zhengpd]

CI failed and branch conflicts. I like this feature.

[vic]

Hi @klane, could you please rebase with master ? :)

[klane]

Will do @vic. I was affected by #634 and haven't had a chance to revisit this. I should be able to resolve the conflicts this weekend if not sooner.

[klane]

While it may not have been this weekend, I rebased with master and fixed the merge conflicts. It took me far longer than I care to admit to notice that a variable was renamed.

I'm not sure why the Unix tests would pass on Ubuntu and fail on macOS, particularly since they pass locally on my Mac. Any suggestions are welcomed.

[lkraider]

Meanwhile I am using:
asdf local python $(asdf latest python)

Would be useful to support .tool-versions with content such as:

python latest

[jthegedus]

@lkraider We only want exact versions in .tool-versions. This PR will allow using global|local with latest to set the version, but it's just a utility to compute the latest and insert it without having to first look it up.

I will work on re-basing this unless someone beats me to it.

[hoov]

I found this because I've had a comment in my ~/.tool-versions for a while ago that relates. While I 100% agree that from a local point of view, it makes sense to always require the explicit version number -- otherwise there's no real point. However, from a global point of view, I want to be able to say "always use the latest 3.9.x version of Python". When I start a new project, that's when I'll freeze the version of Python for that project.

This is even more true given the large number of other tools supported by asdf today. In particular, tools like bat, yq, and even tmux. I was excited when I saw things like this added as plugins, because my use case is having later versions than are provided by a release of Debian. Being able to say "use the latest 3.2.x release of tmux globally" is really handy. It's extra useful because then I can use the same tooling to keep my MacOS system up-to-date, rather than having a split between homebrew and asdf. Perhaps the addition of these extra plugins stretched the use of asdf beyond what it should be used for.

[jthegedus]

@hoov

Perhaps the addition of these extra plugins stretched the use of asdf beyond what it should be used for.

Yes, I think this has become the case. While we won't stop people from creating plugins for whichever tools they like, asdf is a version manager, not a system package manager. We do support system as a version for fallthrough reasons so you can have a non-asdf version managed however you wish for your general system usage. I think the usage you're trying to achieve is extremely difficult, otherwise package managers like Homebrew would have added version managing at the directory level long ago.

[jthegedus]

this check_if_version_exists handles the ref:<ref> & path:<dir> filters two calls deeper in the stack. Those I feel should be elevated to this level as latest:<filter> is handled here.

[jthegedus]

Not suggestion we do this now, but this codebase is becoming spaghetti as everything gets pushed down into utils.bash