Switching from pyenv, rbenv, goenv and nvm to asdf – yujinyuz

This page summarizes the projects mentioned and recommended in the original post on news.ycombinator.com

Our great sponsors
  • Scout APM - Truly a developer’s best friend
  • SonarQube - Static code analysis for 29 languages.
  • talent.io - Download talent.io’s Tech Salary Report
  • asdf

    Extendable version manager with support for Ruby, Node.js, Elixir, Erlang & more

    I used asdf but found it caused a 200ms hit to launching any of the binaries: https://github.com/asdf-vm/asdf/issues/290

    Personally that's not something I can live with as these binaries are sometimes launched many times in subprocesses.

  • direnv

    unclutter your .profile

    > By Ruby, Python and JavaScript hackery I was meaning rvm, venv / pip, and npm. I have the most experience with rvm, and the hackery part comes from the experience when I created a web interface that could instruct the server to do ruby tasks. Turned out that rvm (and also bundler) does a bunch of stuff to the environment of the user, that's sometimes inaccessible, even if you invoke a "login shell" programatically. One of these "hacks" is doing a bunch of stuff when the user navigates to a Ruby project directory with cd, which is when rvm creates or uses the existing virtual env for the project - named is a specific way based on the directory name. I solved this of course but the discovery was quite annoying.

    Keeping the "right context" when you do things in different directories with the same shell config is, unfortunately, a problem that I don't think is easy to solve. My preferred approach is to use direnv (https://direnv.net/), but that's not perfect either.

    As for rvm, I think that a lot of people at some point discovered that rvm was maybe doing a bit too much (in particular, it would also manage gem sets, something that seems superfluous with Bundler). I think that's a reason why rbenv and chruby emerged as lighter-weight alternatives which are a bit less magic. I haven't seen many people use rvm anymore in recent years.

    > Now that I think about it, every single one of the programming ecosystems I used were quite annoying.

    That's something I agree with. As a more recent convert to the JVM world (and mostly just for lack of better alternatives), I'm still sometimes annoyed at the IDE-centrism (and UI-centrism, see also sonarqube) in this space. Luckily, things are already better than they were when I learned Java in university and "it runs in my IDE" was the default state of affairs...

  • Scout APM

    Truly a developer’s best friend. Scout APM is great for developers who want to find and fix performance issues in their applications. With Scout, we'll take care of the bugs so you can focus on building great things 🚀.

  • nixpkgs

    Nix Packages collection

    Nix will even know which packages it'd need to build locally instead of downloading a prebuilt binary.

    You can't do that with other common package managers. You're stuck with whatever the package manager provides you. So if you're not in the happy path, you're out of luck. You'd either have to give up or build from scratch. If you need a bugfix for a particular package, you'd have wait until the fix reaches the package repository. When I was using Ubuntu, that was often until the next major release. None of this stuff is a problem with Nix, which allows for customization with very little effort.

    It's easy to learn about Nix if you know where to look for. Nix Pills [1] would be a good start. The core language is the easiest part. It's JSON, but with functions and variables for proper abstraction. The documentation, while imperfect, is quite extensive compared to numerous other high profile open source projects. If the documentation fails you, the Nixpkgs repository [2] is an even more rich source of information. The code is well organized, and I was able to get familiar with writing Nix packages fairly quickly by grepping the codebase. And finally, Nix has a sizable community so you could always ask if you're stuck.

    [1]: https://nixos.org/guides/nix-pills/

    [2]: https://github.com/NixOS/nixpkgs

  • asdf-direnv

    direnv plugin for the asdf version manager


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

  • nix

    Nix, the purely functional package manager

    If you are looking for a language agnostic version manager, the nix package manager [0] might be worth a try. In combination with lorri [1] you will be dropped into a shell with all required development dependencies available, when you enter the project directory. This does not only include the interpreter/compiler versions but also any other dependency you can think of, like specific libraries the project links against (well almost any, it has to be available as a nix expression, best case directly in upstream nixpkgs).

    [0]: https://nixos.org/

    [1]: https://github.com/nix-community/lorri/

  • asdf-java

    A Java plugin for asdf-vm.

    So is asdf good then? I have been using SDKMAN! to install JDKs, but i noticed that Gradle will automatically detect JDKs installed using SDKMAN!, asdf, and Jabba [1], which signals to me that the other two are worth a look. Although now i dig into it, asdf does not have a first-party Java plugin, so the support is through a third-party plugin maintained by three people and a robot [2].

    [1] https://docs.gradle.org/current/userguide/toolchains.html#se...

    [2] https://github.com/halcyon/asdf-java/graphs/contributors

  • lsp-docker

    Scripts and configurations to leverage lsp-mode in docker environment

    This is a reasonable point, and something that is being worked on. I definitely think Docker can provide LSP servers as necessary, we're just not quite there. This is something that I'm interested in working on, though I'm not the only one: https://github.com/emacs-lsp/lsp-docker

  • SonarQube

    Static code analysis for 29 languages.. Your projects are multi-language. So is SonarQube analysis. Find Bugs, Vulnerabilities, Security Hotspots, and Code Smells so you can release quality code every time. Get started analyzing your projects today for free.

  • dotfiles

    Configuring the universe with Nix. (by samhh)

    I agree that the documentation story could be better. I also think it's a great shame that the language isn't statically-typed, so to understand how to use something I have to inspect its source code.

    I've found it to be quite flexible though. For example, here's a commit in which I apply a patch to a tool to solve a problem that the derivation hadn't taken into account (and absent a home-manager solution): https://github.com/samhh/dotfiles/commit/867dd3b4d4b3942a0aa...

  • eclectica

    ☀️ Cool and eclectic version manager for any language

    I like to use eclectica, it's not very popular, but it works for me


  • rust-overlay

    Pure and reproducible nix overlay of binary distributed rust toolchains

    If it's Rust, you can use https://github.com/oxalica/rust-overlay to get any version you want very easily without pinning an instance of nixpkgs just for it.

    asdf does not allow you to keep three different versions of the same language, so I'm not sure how that compares? It's not super-trivial to do in Nix, but at least you can do it.

    asdf is also no different than Nix when it comes to minor/major versions. You're at the mercy of what the plugin does, other than that you have to create your own plugin from scratch or make a fork. Nix has the option to patch things up more easily at least.

  • poetry2nix

    Convert poetry projects to nix automagically [[email protected]]

  • python-build-standalone

    Produce redistributable builds of Python

    The lack of Ruby support instantly rings an alarm for me because CPython (on POSIX) also is not relocatable, but is listed as support. Turns pit Hermit is actually using a third-party build script[1] instead of the official one. While the python-build-standalone project is quite awesome and indeed is useful for a lot of things, it has enough quirks I would recommend against any generic package distributor to advertise as Python for general use. This in turn makes me lose most confidence on Hermit, unfortunately.

    Be careful if you’re also interested in Hermit. These kinds of things bit you up way down the road when you least expect them to.

    [1] https://github.com/indygreg/python-build-standalone

NOTE: The number of mentions on this list indicates mentions on common posts plus user suggested alternatives. Hence, a higher number means a more popular project.

Suggest a related project

Related posts