fix: support latest with filter on local and global #633

klane · 2020-01-05T20:15:52Z

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 · 2020-03-15T02:23:47Z

CI failed and branch conflicts. I like this feature.

vic · 2020-03-15T02:40:07Z

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

klane · 2020-03-16T15:42:54Z

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 · 2020-03-23T19:50:26Z

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.

lib/utils.bash

- Filter installed versions with asdf list - Use the latest installed version of a tool

Fixes failing CI tests on macOS Co-authored-by: Thomas B Homburg <thomas@homburg.dk>

lkraider · 2021-05-21T20:07:18Z

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

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

python latest

jthegedus · 2021-05-27T01:09:06Z

@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 · 2021-06-04T16:57:20Z

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.

Previous PRs relating to `latest`: * asdf-vm#575 * asdf-vm#633 in July 2021: made it possible to specify `latest` when using the `local` & `global` commands, eg: `asdf local python latest:3.7` - this would save a precise version number to `.tools-versions`, which is undesired behaviour for us at the Guardian.

Previous PRs relating to `latest`: * asdf-vm#575 in November 2019: added the `latest` command, eg `asdf latest python 3.6` reports the latest version of Python 3.6. * asdf-vm#633 in July 2021: made it possible to specify `latest` when using the `local` & `global` commands, eg: `asdf local python latest:3.7` - this would save a precise version number to `.tools-versions`, which is undesired behaviour for us at the Guardian.

### Implementation A new `resolve_version_spec()` function is extracted from the existing `version_command()` function, this takes a version-spec string like `latest:corretto-11` or `corretto-21.0.5.11.1` and resolves it to a definite installed version number (if the resolved version is not installed, the appropriate error message is shown). This new `resolve_version_spec()` function is now called in `select_version()`, used by the `with_shim_executable()` function, meaning that any execution of the `asdf` shim (eg, executing `java`) will now resolve any version specifications found in the `.tool-versions` file - if `.tool-versions` contains `java latest:corretto-21`, this will be resolved and the latest version of Java 21 used. ## Other Information Previous PRs relating to `latest`: * asdf-vm#575 in November 2019: added the `latest` command, eg `asdf latest python 3.6` reports the latest version of Python 3.6. * asdf-vm#633 in July 2021: made it possible to specify `latest` when using the `local` & `global` commands, eg: `asdf local python latest:3.7` - this would save a precise version number to `.tools-versions`, which is undesired behaviour for us at the Guardian.

### Implementation A new `resolve_version_spec()` function has been extracted from the existing `version_command()` function. This takes a version-spec string like `latest:corretto-11` or `corretto-21.0.5.11.1` and resolves it to a definite installed version number (if the resolved version is not installed, the appropriate error message is shown). This new `resolve_version_spec()` function is now called in `select_version()`, used by the `with_shim_executable()` function, meaning that any execution of the `asdf` shim (eg, executing `java`) will now resolve any version specifications found in the `.tool-versions` file - if `.tool-versions` contains `java latest:corretto-21`, this will be resolved and the latest version of Java 21 used. ## Other Information Previous PRs relating to `latest`: * asdf-vm#575 in November 2019: added the `latest` command, eg `asdf latest python 3.6` reports the latest version of Python 3.6. * asdf-vm#633 in July 2021: made it possible to specify `latest` when using the `local` & `global` commands, eg: `asdf local python latest:3.7` - this would save a precise version number to `.tools-versions`, which is undesired behaviour for us at the Guardian.

### Implementation A new `resolve_version_spec()` function has been extracted from the existing `version_command()` function. This takes a version-spec string, like `latest:corretto-11` or `corretto-21.0.5.11.1`, and resolves it to a definite installed version number (if the resolved version is not installed, the appropriate error message is shown). This new `resolve_version_spec()` function is now called in `select_version()`, used by the `with_shim_executable()` function, meaning that any execution of the `asdf` shim (eg, executing `java`) will now resolve any version specifications found in the `.tool-versions` file - if `.tool-versions` contains `java latest:corretto-21`, this will be resolved and the latest version of Java 21 used. ## Other Information Previous PRs relating to `latest`: * asdf-vm#575 in November 2019: added the `latest` command, eg `asdf latest python 3.6` reports the latest version of Python 3.6. * asdf-vm#633 in July 2021: made it possible to specify `latest` when using the `local` & `global` commands, eg: `asdf local python latest:3.7` - this would save a precise version number to `.tools-versions`, which is undesired behaviour for us at the Guardian.

This change enables `asdf`'s existing latest-version-resolution functionality within the `.tool-versions` file itself, ie rather than having to have a `.tool-versions` file that contains a full version number: ``` java corretto-21.0.5.11.1 ``` ...you can now use the same `latest:` syntax that is already available in the `local` & `global` commands, ie: ``` java latest:corretto-21 ``` Currently, using `latew` `asdf local python latest:3.7` ### Implementation A new `resolve_version_spec()` function has been extracted from the existing `version_command()` function. This takes a version-spec string, like `latest:corretto-11` or `corretto-21.0.5.11.1`, and resolves it to a definite installed version number (if the resolved version is not installed, the appropriate error message is shown). This new `resolve_version_spec()` function is now called in `select_version()`, used by the `with_shim_executable()` function, meaning that any execution of the `asdf` shim (eg, executing `java`) will now resolve any version specifications found in the `.tool-versions` file - if `.tool-versions` contains `java latest:corretto-21`, this will be resolved and the latest version of Java 21 used. ## Other Information Previous PRs relating to `latest`: * asdf-vm#575 in November 2019: added the `latest` command, eg `asdf latest python 3.6` reports the latest version of Python 3.6. * asdf-vm#633 in July 2021: made it possible to specify `latest` when using the `local` & `global` commands, eg: `asdf local python latest:3.7` - this would save a precise version number to `.tools-versions`, which is undesired behaviour for us at the Guardian.

This change enables `asdf`'s existing latest-version-resolution functionality within the `.tool-versions` file itself, ie rather than having to have a `.tool-versions` file that contains a full version number: ``` java corretto-21.0.5.11.1 ``` ...you can now use the same `latest:` syntax that is already available in the `local` & `global` commands, ie: ``` java latest:corretto-21 ``` ### Use case In many tool/runtime ecosystems (eg Java), if a program runs correctly under a specific version of that runtime, it can generally be relied on to run correctly under any _later_ version of that runtime with the same major version number (eg if a project runs under Corretto Java 21.0.5.11.1, it will run on any _later_ version of Corretto Java 21). This means that for projects in those ecosystems, there is little incentive to pin to fully-specified versions like `21.0.5.11.1`, and in fact there are downsides - over time, developers default to using older, unpatched versions of Java, unless they are assiduous in continually updating the contents of the `.tool-versions` file, or have tooling devoted to doing so. At the Guardian we have several hundred projects that run on the Java platform, and due to our security observations we generally want to be running under the _latest_ security-patched version of the Java runtime that matches our major-version requirement. We love `asdf` as a tool, and like that the `.tool-versions` file can become a source-of-truth documenting which version of Java a project uses, but we don't want to have to commit fully-specified version numbers like `21.0.5.11.1` to source control, or set up tooling to increment those version numbers across those hundreds of projects. ### Implementation A new `resolve_version_spec()` function has been extracted from the existing `version_command()` function. This takes a version-spec string, like `latest:corretto-11` or `corretto-21.0.5.11.1`, and resolves it to a definite installed version number (if the resolved version is not installed, the appropriate error message is shown). This new `resolve_version_spec()` function is now called in `select_version()`, used by the `with_shim_executable()` function, meaning that any execution of the `asdf` shim (eg, executing `java`) will now resolve any version specifications found in the `.tool-versions` file - if `.tool-versions` contains `java latest:corretto-21`, this will be resolved and the latest version of Java 21 used. ## Other Information Previous PRs relating to `latest`: * asdf-vm#575 in November 2019: added the `latest` command, eg `asdf latest python 3.6` reports the latest version of Python 3.6. * asdf-vm#633 in July 2021: made it possible to specify `latest` when using the `local` & `global` commands, eg: `asdf local python latest:3.7` - this would save a precise version number to `.tools-versions`, which is undesired behaviour for us at the Guardian.

This change enables `asdf`'s existing latest-version-resolution functionality within the `.tool-versions` file itself. Rather than having to have a `.tool-versions` file that contains a full version number: ``` java corretto-21.0.5.11.1 ``` ...you can now use the same `latest:` syntax that is already available in the `local` & `global` commands, ie: ``` java latest:corretto-21 ``` ### Use case For many tool/runtime ecosystems (eg Java), if a program runs correctly under a specific version of that runtime, it can generally be relied on to run correctly under any _later_ version of that runtime with the same major version number (eg if a project runs under Corretto Java 21.0.5.11.1, it will run on any _later_ version of Corretto Java 21). This means that for projects in those ecosystems, there is little incentive to pin to fully-specified versions like `21.0.5.11.1`, and in fact there are downsides - over time, developers will default to using older, unpatched versions of Java, unless they are assiduous in continually updating the contents of the `.tool-versions` file, or have tooling devoted to doing so. At the Guardian we have several hundred projects that run on the Java platform, and due to our security observations we generally want to be running under the _latest_ security-patched version of the Java runtime that matches our major-version requirement. We love `asdf` as a tool, and like that the `.tool-versions` file can become a source-of-truth documenting which version of Java a project uses, but we don't want to have to commit fully-specified version numbers like `21.0.5.11.1` to source control, or set up tooling to increment those version numbers across those hundreds of repositories. Allowing the use of `latest:` in the `.tool-versions` file means that we don't need to continually update those `.tool-versions` files. It also partially addresses some of the needs raised by asdf-vm#1736, though this solution uses the existing `asdf` version-resolution functionality, rather than adopting the version requirements system used in nodejs. ### Implementation A new `resolve_version_spec()` function has been extracted from the existing `version_command()` function. This takes a version-spec string, like `latest:corretto-11` or `corretto-21.0.5.11.1`, and resolves it to a definite installed version number (if the resolved version is not installed, the appropriate error message is shown). This new `resolve_version_spec()` function is now called in `select_version()`, used by the `with_shim_executable()` function, meaning that any execution of the `asdf` shim (eg, executing `java`) will now resolve any version specifications found in the `.tool-versions` file - if `.tool-versions` contains `java latest:corretto-21`, this will be resolved and the latest version of Java 21 used. ## Other Information Previous `asdf` PRs relating to `latest`: * asdf-vm#575 in November 2019: added the `latest` command, eg `asdf latest python 3.6` reports the latest version of Python 3.6. * asdf-vm#633 in July 2021: made it possible to specify `latest` when using the `local` & `global` commands, eg: `asdf local python latest:3.7` - this would save a precise version number to `.tools-versions`, which is undesired behaviour for us at the Guardian. A couple of Guardian systems attempting to standardise on using `.tool-versions` as a source of truth: * guardian/gha-scala-library-release-workflow#36 * https://github.com/guardian/setup-scala

This change enables `asdf`'s existing latest-version-resolution functionality within the `.tool-versions` file itself. Rather than having to have a `.tool-versions` file that contains a full version number: ``` java corretto-21.0.5.11.1 ``` ...you can now use the same `latest:` syntax that is already available in the `local` & `global` commands, ie: ``` java latest:corretto-21 ``` ### Use case For many tool/runtime ecosystems (eg Java), if a program runs correctly under a specific version of that runtime, it can generally be relied on to run correctly under any _later_ version of that runtime with the same major version number (eg if a project runs under Corretto Java 21.0.5.11.1, it will run on any _later_ version of Corretto Java 21). This means that for projects in those ecosystems, there is little incentive to pin to fully-specified versions like `21.0.5.11.1`, and in fact there are downsides - over time, developers will default to using older, unpatched versions of Java, unless they are assiduous in continually updating the contents of the `.tool-versions` file, or have tooling devoted to doing so. At the Guardian we have several hundred projects that run on the Java platform, and due to our security obligations we generally want to be running under the _latest_ security-patched version of the Java runtime that matches our major-version requirement. We love `asdf` as a tool, and like that the `.tool-versions` file can become a source-of-truth documenting which version of Java a project uses, but we don't want to have to commit fully-specified version numbers like `21.0.5.11.1` to source control, or set up tooling to increment those version numbers across those hundreds of repositories. Allowing the use of `latest:` in the `.tool-versions` file means that we don't need to continually update those `.tool-versions` files. It also partially addresses some of the needs raised by asdf-vm#1736, though this solution uses the existing `asdf` version-resolution functionality, rather than adopting the version requirements system used in nodejs. ### Implementation A new `resolve_version_spec()` function has been extracted from the existing `version_command()` function. This takes a version-spec string, like `latest:corretto-11` or `corretto-21.0.5.11.1`, and resolves it to a definite installed version number (if the resolved version is not installed, the appropriate error message is shown). This new `resolve_version_spec()` function is now called in `select_version()`, used by the `with_shim_executable()` function, meaning that any execution of the `asdf` shim (eg, executing `java`) will now resolve any version specifications found in the `.tool-versions` file - if `.tool-versions` contains `java latest:corretto-21`, this will be resolved and the latest version of Java 21 used. ## Other Information Previous `asdf` PRs relating to `latest`: * asdf-vm#575 in November 2019: added the `latest` command, eg `asdf latest python 3.6` reports the latest version of Python 3.6. * asdf-vm#633 in July 2021: made it possible to specify `latest` when using the `local` & `global` commands, eg: `asdf local python latest:3.7` - this would save a precise version number to `.tools-versions`, which is undesired behaviour for us at the Guardian. A couple of Guardian systems attempting to standardise on using `.tool-versions` as a source of truth: * guardian/gha-scala-library-release-workflow#36 * https://github.com/guardian/setup-scala

This change enables `asdf`'s existing latest-version-resolution functionality within the `.tool-versions` file itself. Rather than having to have a `.tool-versions` file that contains a full version number: ``` java corretto-21.0.5.11.1 ``` ...you can now use the same `latest:` syntax that is already available in the `local` & `global` commands, ie: ``` java latest:corretto-21 ``` ### Use case For many tool/runtime ecosystems (eg Java), if a program runs correctly under a specific version of that runtime, it can generally be relied on to run correctly under any _later_ version of that runtime with the same major version number (eg if a project runs under Corretto Java 21.0.5.11.1, it will run on any _later_ version of Corretto Java 21). This means that for projects in those ecosystems, there is little incentive to pin to fully-specified versions like `21.0.5.11.1`, and in fact there are downsides - over time, developers will default to using older, unpatched versions of Java, unless they are assiduous in continually updating the contents of the `.tool-versions` file, or have tooling devoted to doing so. At the Guardian we have several hundred projects that run on the Java platform, and due to our security obligations we generally want to be running under the _latest_ security-patched version of the Java runtime that matches our major-version requirement. We love `asdf` as a tool, and like that the `.tool-versions` file can become a source-of-truth documenting which version of Java a project uses, but we don't want to have to commit fully-specified version numbers like `21.0.5.11.1` to source control, or set up tooling to increment those version numbers across those hundreds of repositories. Allowing the use of `latest:` in the `.tool-versions` file means that we don't need to continually update those `.tool-versions` files. It also partially addresses some of the needs raised by asdf-vm#1736, though this solution uses the existing `asdf` version-resolution functionality, rather than adopting the version requirements system used in nodejs. ### Implementation A new `resolve_version_spec()` function has been extracted from the existing `version_command()` function. This takes a version-spec string, like `latest:corretto-11` or `corretto-21.0.5.11.1`, and resolves it to a definite installed version number (if the resolved version is not installed, the appropriate error message is shown). This new `resolve_version_spec()` function is now also called in `select_version()`, used by `with_shim_executable()`, meaning that any execution of the `asdf` shim (eg, executing `java`) will now resolve any version specifications found in the `.tool-versions` file - if `.tool-versions` contains `java latest:corretto-21`, this will be resolved and the latest version of Java 21 used. ## Other Information Previous `asdf` PRs relating to `latest`: * asdf-vm#575 in November 2019: added the `latest` command, eg `asdf latest python 3.6` reports the latest version of Python 3.6. * asdf-vm#633 in July 2021: made it possible to specify `latest` when using the `local` & `global` commands, eg: `asdf local python latest:3.7` - this would save a precise version number to `.tools-versions`, which is undesired behaviour for us at the Guardian. A couple of Guardian systems attempting to standardise on using `.tool-versions` as a source of truth: * guardian/gha-scala-library-release-workflow#36 * https://github.com/guardian/setup-scala

This change enables `asdf`'s existing latest-version-resolution functionality within the `.tool-versions` file itself. Rather than having to have a `.tool-versions` file that contains a full version number: ``` java corretto-21.0.5.11.1 ``` ...you can now use the same `latest:` syntax that is already available in the `local` & `global` commands, ie: ``` java latest:corretto-21 ``` ### Use case For many tool/runtime ecosystems (eg Java), if a program runs correctly under a specific version of that runtime, it can generally be relied on to run correctly under any _later_ version of that runtime with the same major version number (eg if a project runs under Corretto Java 21.0.5.11.1, it will run on any _later_ version of Corretto Java 21). This means that for projects in those ecosystems, there is little incentive to pin to fully-specified versions like `21.0.5.11.1`, and in fact there are downsides - over time, developers will default to using older, unpatched versions of Java, unless they are assiduous in continually updating the contents of the `.tool-versions` file, or have tooling devoted to doing so. At the Guardian we have several hundred projects that run on the Java platform, and due to our security obligations we generally want to be running under the _latest_ security-patched version of the Java runtime that matches our major-version requirement. We love `asdf` as a tool, and like that the `.tool-versions` file can become a source-of-truth documenting which version of Java a project uses, but we don't want to have to commit fully-specified version numbers like `21.0.5.11.1` to source control, or set up tooling to increment those version numbers across those hundreds of repositories. Allowing the use of `latest:` in the `.tool-versions` file means that we don't need to continually update those `.tool-versions` files. It also partially addresses some of the needs raised by asdf-vm#1736, though this solution uses the existing `asdf` version-resolution functionality, rather than adopting the version requirements system used in nodejs. ### Implementation A new `resolve_version_spec()` function has been extracted from the existing `version_command()` function. This takes a version-spec string, like `latest:corretto-11` or `corretto-21.0.5.11.1`, and resolves it to a precise version number. This new `resolve_version_spec()` function is now also called in `select_version()`, used by `with_shim_executable()`, meaning that any execution of the `asdf` shim (eg, executing `java`) will now resolve any version specifications found in the `.tool-versions` file - if `.tool-versions` contains `java latest:corretto-21`, this will be resolved and the latest version of Java 21 used. ## Other Information Previous `asdf` PRs relating to `latest`: * asdf-vm#575 in November 2019: added the `latest` command, eg `asdf latest python 3.6` reports the latest version of Python 3.6. * asdf-vm#633 in July 2021: made it possible to specify `latest` when using the `local` & `global` commands, eg: `asdf local python latest:3.7` - this would save a precise version number to `.tools-versions`, which is undesired behaviour for us at the Guardian. A couple of Guardian systems attempting to standardise on using `.tool-versions` as a source of truth: * guardian/gha-scala-library-release-workflow#36 * https://github.com/guardian/setup-scala

klane force-pushed the use-latest branch from 848b7bc to 4254190 Compare January 7, 2020 21:15

klane mentioned this pull request Jan 8, 2020

Errors when running bats test locally #634

Closed

klane force-pushed the use-latest branch from 4254190 to 62fde34 Compare March 23, 2020 19:15

homburg suggested changes May 13, 2020

View reviewed changes

lib/utils.bash Outdated Show resolved Hide resolved

klane requested a review from a team as a code owner May 13, 2020 23:35

klane force-pushed the use-latest branch from 22997ce to ed9b6e7 Compare May 14, 2020 14:33

klane and others added 14 commits May 14, 2020 07:39

Move command that returns the latest version to a utility function

537472c

Add support for filtering installed versions with asdf list

9c82d11

Add support for using the latest installed version of a tool

e1331cd

Add tests for new features

c1bcade

- Filter installed versions with asdf list - Use the latest installed version of a tool

Update documentation with new features

7291d97

- Filter installed versions with asdf list - Use the latest installed version of a tool

Fix shellcheck errors

5a084b2

Add error messages when filtering yields no compatible versions

ad53811

Remove unnecessary echo flags

8f5fb89

Rearrange asdf list error messages to retain original behavior

23575a2

Improve version filtering error messages and exit codes

163aca7

Add tests for version filtering error messages

1bb167d

Rename variable to account for previous name change

be68403

Move changes to latest version in CHANGELOG

b787fe8

Replace sed with awk to get the latest version of a tool

00bcb8b

Fixes failing CI tests on macOS Co-authored-by: Thomas B Homburg <thomas@homburg.dk>

klane force-pushed the use-latest branch from ed9b6e7 to 00bcb8b Compare May 14, 2020 14:49

kirintwn mentioned this pull request Jun 29, 2020

asdf: add install & global latest version of plugin scripts kirintwn/dotfiles#1

Closed

jthegedus mentioned this pull request May 27, 2021

latest targets for asdf global/local #951

Closed

jthegedus changed the title ~~Add support for using the latest installed version of a tool~~ fix: support latest with filter on local and global Jul 6, 2021

jthegedus merged commit 5cf8f89 into asdf-vm:master Jul 6, 2021

jthegedus added a commit that referenced this pull request Jul 8, 2021

fix: help text as per new feats in #633

e98ef9d

jthegedus mentioned this pull request Jul 8, 2021

fix: help text as per new feats in #633 #991

Merged

jthegedus added a commit that referenced this pull request Jul 8, 2021

fix: help text as per new feats in #633 (#991)

0d95663

klane deleted the use-latest branch July 15, 2021 15:02

rtyley mentioned this pull request Oct 17, 2024

feat: Enable use of latest: in .tool-versions files #1793

Open

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

fix: support latest with filter on local and global #633

fix: support latest with filter on local and global #633

klane commented Jan 5, 2020 •

edited

Loading

zhengpd commented Mar 15, 2020

vic commented Mar 15, 2020

klane commented Mar 16, 2020

klane commented Mar 23, 2020

lkraider commented May 21, 2021 •

edited

Loading

jthegedus commented May 27, 2021 •

edited

Loading

hoov commented Jun 4, 2021

fix: support latest with filter on local and global #633

fix: support latest with filter on local and global #633

Conversation

klane commented Jan 5, 2020 • edited Loading

Summary

zhengpd commented Mar 15, 2020

vic commented Mar 15, 2020

klane commented Mar 16, 2020

klane commented Mar 23, 2020

lkraider commented May 21, 2021 • edited Loading

jthegedus commented May 27, 2021 • edited Loading

hoov commented Jun 4, 2021

klane commented Jan 5, 2020 •

edited

Loading

lkraider commented May 21, 2021 •

edited

Loading

jthegedus commented May 27, 2021 •

edited

Loading