Support "latest" in .tool-versions

[cj81499]

Is your feature request related to a problem? Please describe

I would like the default version of various tools on my system to always be the latest available version.

Describe the proposed solution

I propose adding support for the special value "latest" within .tool-versions files. It would evaluate to the latest available version for that particular tool.

One concern I see with this is the need to frequently check for updates to a given tool. To avoid this, available versions of a tool could be cached for some duration. Ideally, this duration would be configurable by the user.

Describe similar asdf features and why they are not sufficient

Currently, I can run asdf global my-tool latest, and the version in my global settings (~/.tool-versions) will be set to the latest available version. However, when a new version of the tool is released, the default remains set to whatever value latest evaluated to when I last ran the command.

Describe other workarounds you've considered

I've considered changing my .zshrc file to check for updates at shell launch, but this obviously has a significant negative impact on shell startup time.

Another possible workaround is a cron job that would run a script to check for updates. This would work, but I ultimately feel this functionality may be useful enough to justify being built-in.

[jthegedus]

Updating your global deps is something you can script and run in user space, similar to most system package managers where installation of updates is opt-in on an update by update basis (note that asdf is not itself a package manager).

We do not want to support this type of feature in asdf. Here is an explanation from another discussion:

Special versions like latest are resolved at the time the asdf command specifying them is run and are not permitted to in .tool-versions because of the nondeterminism they would introduce. We don't want to allow any variability in versions specified in any of the version files that asdf supports because we want asdf to be deterministic. We don't want a new version release to accidentally pull the rug out from under someone because they had specified a shorthand version or version range. This constraint allows us to provide stronger guarantees about asdf behavior.
-@Stratus3D in asdf-vm/asdf-nodejs#235

@Stratus3D I will PR an FAQ item for this issue so we can link to it in future. And and also propose an update to the legacy versions file support docs so we can link to it in discussions like asdf-vm/asdf-nodejs#235.

[Stratus3D]

@Stratus3D I will PR an FAQ item for this issue so we can link to it in future. And and also propose an update to the legacy versions file support docs so we can link to it in discussions like asdf-vm/asdf-nodejs#235.

Thanks, sounds good!