support for semver version range backed by package provider chain would make asdf a more useful version manager

[lestephane]

Is your feature request related to a problem? Please describe

I understand that .tool-versions is focused on getting everyone on the same version, but sometimes people lag behind because they only can install a version of a program from the OS package manager. A version that might nevertheless be good enough for the project.

Example: I need in my repo pre-commit hook the git branch --list command to reflect the case where there is an ongoing rebase, so any version >= 2.18 is good enough.

I would like to be able to write in .tool-versions something like

git ^2.18.0

Describe the proposed solution

Write in .tool-versions

git ^2.18.0

Run asdf install

• If my path has has a version that satisfies the range, it's used, otherwise...
• If my os package-manager has a version that satisfies the range, it's installed and used, otherwise...
• If my local homebrew has a version that satisfies the range, it's installed and used, otherwise...
• (insert your own package manager here, the list is ranked according to user preferences)
• If the git asdf plugin is installed, forward the install command to it
• If the git asdf plugin is not installed, there is an error, because the user must install the plugin first.

I personally don't install asdf plugins that are neither from the core repo nor from the community repo.

But git in my 20.04 LTS Ubuntu is still going to receive security updates for a while, and if it's good enough for the version range, why not use that?

$ apt-cache madison git
       git | 1:2.25.1-1ubuntu3.6 | https://mirrors.edge.kernel.org/ubuntu focal-security/main amd64 Packages

And if I happen to have homebrew and have installed an even more recent version of it, and it's good enough for the version range, why not use that?

$ brew list --versions git
git 2.37.3

And if none work, and I am willing to install the relevant plugin, it would be nice for it to support the semver directly from the CLI

$ asdf local python ^3.10
version ^3.10 is not installed for python

(I had to use python here, because I don't intend to install the git plugin)

Describe similar asdf features and why they are not sufficient

Directing asdf to use the system git requires the git plugin, which I'm not going to install (as described in the proposed solution)

$ asdf local git system
No such plugin: git

Even if I did, this will not guarantee that the system version matches the requirement set out in .tool-versions. That part would still have to be done by the user.

Describe other workarounds you've considered

I'm not aware of any version manager that is trying to attempt this kind of semver based tool version convergence across

• OS package manager
• secondary package manager (snap, homebrew, ...)
• asdf plugins

I'm well aware that this is not a design goal of asdf, but I needed to put it out there.

[hyperupcall]

I think having symbols like ^ and ~ are useful in specifying semver-like version ranges are useful, especially for keepig up with patch releases, and could potentially be opened up in a separate issue.

I understand that .tool-versions is focused on getting everyone on the same version, but sometimes people lag behind because they only can install a version of a program from the OS package manager. A version that might nevertheless be good enough for the project.

I think the whole point of asdf is to have a mechanism independent of the OS package manager, since OS package managers they tend to be out of date, unreliable, or too annoying to use (adding external repos, etc.). I would say falling back to installing from the package manager before from an asdf plugin is definitely not good.

Using a OS package managers introduces a lot of problems. It introduces non-determinism in an asdf install command and may needlessly cause more users to run to us when there are installation problems; when really, the problem is with an OS package manager. For example, just last year, an installation of NodeJS on ZorinOS is unusable because by default, npm couldn't be used without sudo (personal experience; hopefully it's fixed by now, but there are bound to be plenty of caveats). Distros also don't always package the same binaries, there could be multiple packages from different release repositories, and we would also have to consider rolling release distributions. I also don't like that this change it would prompt for a sudo password, which is a breaking change for many automated scripts already using asdf.

I think a general tool that abstracts OS package-manager commands is a venerable goal in general (and i wish such a tool was commonplace), and your proposed idea can fit very well into it, but I think it's a feature for a separate project.

Same thing with a tool that checks if verisons in the path are the same as those specified in the .tool-versions; great idea, wish it existed, but it should be implementaed in a separte tool.

So my vote is to close this issue since it's out of scope.

[hyperupcall]

Related to #352

[mpql]

I agree that asdf runs counter to relying on OS package managers, but I feel I've got to disagree that this is out of scope. I don't see any reasoning for why this feature would belong to a separate project. To count, version pinning can be explicit, yes, but the scope of how explicit that pinning is should be decided by the user.

Per the use case in OP, if a user is looking to use a feature that is available starting in git 2.18.0, a pin of git ^2.18.0 is a perfectly reasonable -- and I'd even say expected -- solution.

To throw my own use case onto the pile, consider:

• Python 3.10 is just releasing maintenance / security patches at this point.
• I'm entering the project for an inherited codebase that specifically requires Python 3.10
• I pinned latest:3.10 at a time when that resolved to 3.10.12
• I've since upgraded my 3.10 to 3.10.13, and uninstalled 3.10.12

Desired behavior:

• Specify e.g. asdf local python <version>, with version being something like one of:
  • 3.10
  • latest:3.10
  • ^3.10.12

Actual behavior:

• asdf resolves python at the time of version pinning, python pinned at 3.10.12.
• Trying to run python results in my environment unable to find it
• Current workaround would require me to update every single .tool-versions file for every project where I may wish to run a specific minor point version of any patch.

I have to think far more use cases would benefit from more flexible version pinning, as opposed to necessarily experiencing dependency rot for want of an >= feature.