Asdf: Support using "latest" version of a program (`asdf {global,local,shell} <plugin> latest`)

Created on 11 Sep 2020  路  5Comments  路  Source: asdf-vm/asdf

asdf kind of knows what version latest is describing and allows installing the latest version of a program with asdf install <plugin> latest, but setting the latest version of a program in the shell, in a directory, or globally requires specifying the exact version.

Example:

# asdf install jbang latest
# jbang version
No version set for command jbang
Consider adding one of the following versions in your config file at /Users/joschi/.tool-versions
jbang 0.45.0
# asdf shell jbang latest
version latest is not installed for jbang

Describe the solution you'd like

It would be great if asdf {global,local,shell} <plugin> <version> supported latest as version.

# asdf install jbang latest
# asdf shell jbang latest
# jbang version
0.45.0

Ideally the version ending up in .tool-versions would be the resolved latest version of the program, e. g. jbang 0.45.0 in the example above.

asdf already supports this with asdf latest <plugin>.

enhancement help wanted

Most helpful comment

I would also be fine with doing asdf <global|shell|local> <plugin> latest and having it resolve latest version and put that version number in the .tool-versions file.

That's what the PR #802 is doing. 馃槉

All 5 comments

Currently latest is resolved by asdf, though the implementation should defer to the plugin to determine what "latest" means for that plugin's ecosystem, see https://github.com/asdf-vm/asdf/issues/763

latest in the .tool-versions file is a bad idea IMO as it removes guarantees asdf provides that each person is on a specific version.

Examples of potential problems with this feature:

  • If I have no network access, asdf is unable to perform asdf list all <tool> to determine latest, what happens in this case?
  • If I have an older version of the plugin itself to my colleagues, then latest may resolve to a different provider leading to erroneous behaviour (EG: Python or Java plugins added a new provider which the project uses but I cannot see this).

I'm sure there are more scenarios like this.

Requiring specific versions, while strict, removes a class of issues and is the intended goal of asdf to manage a projects tools' versions.

latest in the .tool-versions file is a bad idea IMO as it removes guarantees asdf provides that each person is on a specific version.

That's what I meant with "Ideally the version ending up in .tool-versions would be the resolved latest version of the program". 馃槂

Sorry, I didn't understand that to be what you meant. If it worked that way, then it doesn't have any issues I can think of off the top of my head :+1:

I would also be fine with doing asdf <global|shell|local> <plugin> latest and having it resolve latest version and put that version number in the .tool-versions file.

For example:

$ asdf latest ruby
ruby 2.7.1
$ asdf local ruby latest
# .tool-versions
ruby 2.7.1

I would also be fine with doing asdf <global|shell|local> <plugin> latest and having it resolve latest version and put that version number in the .tool-versions file.

That's what the PR #802 is doing. 馃槉

Was this page helpful?
0 / 5 - 0 ratings