[ufmace]

I routinely work in Ruby, Python, Javascript, Java, Go, and Rust. The thing that drives me to use asdf is that without such a tool, every language needs a different version or installation manager and they all work slightly differently. It's a hassle to remember 6 different sets of commands for how to install a new version, check which version is active, switch to a different version, and to remember the slightly different quirks that each language's tool has. With asdf, they all work exactly the same. Granted that with Rust and Go it's usually less necessary to keep older versions around, but you definitely need it for Python and Ruby. Better to have all the languages work the same even if it's a bit more complex than needed for some.

[karmakaze]

Ok, so then it's like a package manager manager. Does it update each package manager's lock files too?

Thanks all for the replies. And sorry if I'm asking basic questions and should just read the asdf readme. On my custom layout I have to type A-S-R-H to get asdf.

[RulerOf]

> Ok, so then it's like a package manager manager.

Still no. asdf manages the versions of the runtimes themselves. E.g. I have a project that uses ruby 2.7.2 and Terraform 1.1.7. If I'm using asdf, I declare this in the .tool-versions file of the project, and then when I navigate to that directory, every invocation of `ruby` or `terraform` will run those exact versions.

Separately, packages (Ruby Gems, Python packages, etc) will also be isolated per-version of each runtime, but that's a side effect rather than the goal with asdf.

[ufmace]

Actually no, it manages the versions of the languages themselves, but doesn't interact with their package managers at all. The .tool-versions file it uses to mark the current version could be thought of as a lock file as well. It replaces (for Ruby) rbenv/rvm, not rubygems. Rustup, not Cargo, etc.