Hacker News Reader

Comment by wyuenho | Hacker News Reader

asdf is not a replacement for pyenv, rbenv, goenv and nvm, it's yet another abstraction on top of them. Nvm is a fork of rbenv for node, and pyenv is a fork of rbenv for python, the core of all of these asdf plugins are exactly ruby-build, python-build and node-build, which came from rbenv, pyenv and nodeenv. For go, you don't need any kind of environment, you can switch between versions with just a change of an environment variable. Also, a much simpler solution is to simply install these language runtime versions with your favorite package manager like Homebrew or Macports, and use direnv and dotenv to switch between them as you cd into different directories. All of these languages have convenient environment variables you can control to put the right things in your paths.

View on HN

> asdf is not a replacement for pyenv, rbenv, goenv and nvm, it's yet another abstraction on top of them

No, asdf is a replacement for them. It's not an abstraction on top of them. It uses its own plugin system, and everything is written purely in bash. Everything gets installed in `~/.asdf/installs`

Their "plugins", are using exactly the same build plugins pyenv, rbenv and nodeenv use to build the language runtimes. All asdf does is set the point things to the right directories using various tricks like symlinks and shims and whatnot. This is something easily accomplished by direnv.

https://github.com/asdf-community/asdf-direnv

> asdf version resolution is slow which makes every command execution pay that penalty. asdf reshim is needed for finding new executables, and some tools are not happy with their executables being masked by shims.

> Perform asdf version resolution only once and defer environment loading to direnv.

Exactly the reason to use direnv directly.

but then I still have to use some kind of package manager to manage multiple language runtime versions and brew/apt/dnf are all woefully inadequate

What's so inadequate? When you deploy, your CI/CD pipeline and production don't run on the apt/dnf versions of the language runtime?

Our infrastructure runs on Ubuntu 20.04 across the board but, for example, our main Ruby on Rails monolith runs Ruby 3.0, but Canonical only packages 2.7 for Focal. We have a legacy service which runs on 2.5 and a few microservices that run on 2.7. Having language versions tied to specific OS versions was a massive PITA for us in the past, now it doesn't even really matter all the much what OS is running the code. If we just used apt versions we'd be stuck on Ubuntu 18.04 for ruby 2.5 and we'd have to ugprade the entire application in order to get it to run on 20.04 once it goes out of support. Yuck

Nevermind trying to setup a development environment where you have multiple dependencies on different language runtimes.

> install these language runtime versions with your favorite package manager like Homebrew or Macports

Package managers often don't have a way to install specific old versions of a package, or multiple versions of a single package. That's the whole point.

Yes there is, but may not be granular enough to the patch level, they usually end at the major or minor level. But then again, I've never ran into or heard of anyone that needs a very specific semver of a language runtime for a project. It could happen, and when it does, you switch to pyenv, rbenv or nvm. There's still not a reason to use asdf, as a poster pointed out, asdf version resolution is slow and you need to reshim, which is yet another manual intervention you'll need to do.

Nit: nvm is fork of rvm. nodenv is fork of rbenv. The rbenv model works much better than nvm model because it uses PATH executables instead of heavy shell functions.

Regarding the suggestion to “do things manually” — what is the value of doing things manually? For me, it is very far away from how I want to spend my energy, which is doing computer things that only I can do. I am happy to outsource environment variable fiddle faddling to someone else.

Configuration is a necessity for any tooling. Direnv is something you likely already use with dotenv anyway to configure your CI/CD pipelines. All you need to do is to drop in a few more extra environment variables into your git worktree.

I also prefer `direnv`. I am not entirely sure how `asdf` actually works; `direnv` is pretty straightforward: it hooks into the shell and modifies environment variables. (`PATH`, but also tool-specific variables if required.) So it's pretty easy to debug or replicate by hand if necessary.

It can't actually install different versions though (looks like `asdf` can?), which is somewhat inconvenient.

Just install them with Homebrew or Macports. They all get installed into different paths anyway and you don't even need to build from source on your system. Building python and node are major PATA.

Reply on news.ycombinator.com