10 ms·

> 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 abstra

by lapser 5y ago

> 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`

wyuenho 5y ago
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.
- rubyist5eva 5y ago
  https://github.com/asdf-community/asdf-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.
  - wyuenho 5y ago
    Exactly the reason to use direnv directly.
    - rubyist5eva 5y ago
      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
      - wyuenho 5y ago
        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?
        rubyist5eva 5y ago
        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.

by lapser 5y ago

wyuenho 5y ago

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.

rubyist5eva 5y ago
https://github.com/asdf-community/asdf-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.
- wyuenho 5y ago
  Exactly the reason to use direnv directly.
  - rubyist5eva 5y ago
    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
    - wyuenho 5y ago
      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?
      - rubyist5eva 5y ago
        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.