Install Asdf: One Runtime Manager to Rule All Dev Environments (opens in new tab)

No disrespect to mise but this what’s so frustrating about the industry. Just as one starts getting popular, some people move on to something “better”.

Mise/rtx doesn't cut it for us. It's approach is shell-based, so if your programs launch sub-processes, mise won't be applied. So for example Node scripts running in version 18 might npm run a process, which gets launched with the system node.js version.

Where-as asdf creates shims that go into the PATH. That way any processes launching processes using normal env rules have asdf applied.

Mise looks well built & is very fast. But it's jaw dropping to me that it's coverage is so drastically lower than asdf.

I did the same. mise is brilliant! For reference it was previously called rtx

The main differences are better UX with simpler commands and it not using shims, which means much better performance

I still prefer asdf. It does the job just fine. Direnv has its own stdlib, which sometimes I find useful, and make is something I have to install anyway.

I recently started using https://github.com/prefix-dev/pixi for Python projects. I really love it so far, but this tool looks a bit more mature, which makes sense considering pixi is relatively new.

Ah - was just about to come and post exactly the same thing. Mise is fantastic, supports everything ASDF does and is faster.

+1

One of my pet peeves with tooling these days is the completely random naming. Literally no effort made, whatsoever, to come up with something vaguely descriptive. Neovim plugins are the worst for this. They're comically badly named.

I raised this complaint before and learned that most people using the "new" one have never even heard of Common Lisp, and certainly not of its own "asdf" system.

What's the "original asdf?"

People complain a lot about NPM, but I find it solves all these problems reasonably nicely. It's pretty easy to use in development and it's easy to deploy (either using node_modules in production, or bundling, both approaches work).

Of course it only works if your codebase and tools are all JS-based!

Having worked recently on a project that was mostly TypeScript with some Python, the TS bits were mostly straightforward but the Python was a hassle in both dev and production (I used venv). I can see that asdf might have been handy for development but if it didn't have a good deployment workflow that wouldn't have helped.

> I don’t think it’s a good idea to simply replace rbenv/nvm/etc with asdf-ruby-plugin and so on

ASDF generally doesn't reinvent version management, but wrap and re-use ruby-build, node-build etc.

It fails if your single project is a legacy monster needing four versions of node, two pythons and a handful of javas - but that's not a common use case.

More commonly you have multiple projects, each with a single version of node, python and java. For deployment you only need one of each - it's in development you need five of each when switching between projects.

Having tried asdf - among other tools - for awhile, dropping it for nix+flakes+direnv was great.

Devenv seems nice (in fact it’s how I started down this path) but I haven’t found anything it does for me that I can’t get out of flakes - so far.

Yeah… but then you get nix’s problems.

- steep steep learning curve, so your team is split between those who can understand it and those who have to blindly follow checklists and ask for help when something breaks

- it doesn’t play well on macOS

> Why would I want/need this?

always, golang is overly opinionated regarding where modules and binaries are stored. I don't like that and I've blown my local development environment into pieces because of that (looking at you GRPC, yikes)

But also, imagine that you, like me, need to test Python, Java+Kotlin+Gradle and NodeJS+Angular stuff. Do you really want to install _all that_ natively ? Just for a couple of merge reviews, and even if not, do you _really_ want to install all that natively ? The answer is always, IMHO, a resounding and clear no.

> It was a Visual Basic 6 program, so I just took two half days going through every EXE & DLL related to Windows and VB, eventually finding the difference. Tedious but not rocket science. Is it to avoid these cases?

For example, but also much worst, as mentioned in the OP it's to prevent the very real possibility of crippling your OS's language runtimes and also to stay productive.

I work in about 5-10 versions of Elixir depending on a similar number of specific Erlang versions. At any given time. Also 2-3 NodeJS versions.

It is quite helpful. Also incredibly practical when chevking whether Library X will work on an older version.

I do open source and consulting for clients. I deal with a lot of projects, my own and other's.

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.

there's something I don't get, why do you have globally installed tools that asdf can manage at the same time that you have asdf installed?

Also moved to immutable Fedora, and had to move away from doing `pacman -S go python node` on the host for all my dev tools. Tried to keep doing that in a distrobox, but it kept breaking due to me not updating it. Then I started building my own toolbox container with all I need in it for local consumption from GHCR, and that works a bit better, but recreating it is still annoying. I ended up using Devbox as a Nix wrapper for many new projects, but those could all use asdf/mise too, and I might consider switching some over.

One project of mine, though, requires a shareable / pseudo-reproducible dev environment. Devbox didn't cut it, and mise especially couldn't have, since it requires some system deps. I went with a Nix Flake, which worked fine, but also started building a special distrobox image for the project, this time udimg Fedora as a base, as I perceived it as more stable. Using it too distrobox still had some issues, but I managed to make a shim/helper that runs `pnpm` from inside the container and that works pretty perfectly. Might be a bit worse on the performance side, though. We'll see.

Nice, I've been thinking about building something similar. However, I'd still like to use my shell configuration/dotfiles inside the container (and I'd like my team mates to be able to do the same) and, so far, I haven't really found a good solution for that.

> I had to install a couple of alternative python versions on my dev machine at work and found it was easiest for me to just build from source and `make altinstall` with a custom prefix set.

That's basically what asdf does, just automated.

If you have a requirement for multiple, specific Python versions, why not just use pyenv?

https://github.com/pyenv/pyenv

How do you update the list of installed python versions?

Generally asdf shines when you need more than one system installed - say a html or SQL language server that depends on node in addition to python for your main app.

Mise gives you basically the same capabilities but is scoped a bit better, I’d check it out.

it certainly looks interesting! I'm still not sure if "It’s npx for everything else" is good marketing :P

> can activate project tooling upon cd’ing into a project folder

this probably can be replicated with zsh hooks: https://zsh.sourceforge.io/Doc/Release/Functions.html#Hook-F...

wait wuuut? I don't get it, I do this with asdf using the `.tool-versions` file. What's the difference/improvement?

it portability

OP here, although I hoped I took an example that was relatable, it seems it wasn't as relatable as I expected.

> Is it just me that never even wants to get to the problems that asdf attempts to solve?

You aren't alone, the scenario isn't ideal. However, brew's Python installation on MacOS as are Debian's and Ubuntu's are _extremely_ brittle. You are one cask, formulae or apt package away from needing to do a weekend-long spelunking session or a full blown system re-install if you have deadlines.

PyEnv is a pain to set up, and maintain, which is what I used in the years before as well as after Python 2 was deprecated and projects started slowly migrating to newer python versions.

> That example in the article of managing multiple python 2.7 versions sounds like a horror story.

It is a horror story, but is very common.

Have you tried to install and maintain Java, Kotlin and Graddle installations for a given project although your machine is not primarily a Java, Kotlin, Graddle box? That is a real nightmare, not so much with asdf.vm.

Indeed, hence my name.

The sheer amount of wasted time is hard to comprehend. How many man-hounrs or rather man-centuries have we spent trying to make python fast and trying to install it?. We just keep on polishing that turd.

just curious, have you tried using asdf.vm with pipenv ? I've never needed anything else and have yet to have any problems.

A couple of moons ago I used Poetry, but gave up on it because it was so heavy and unfortunately would bug out often.

Development inside a container is still pretty darn miserable though.

Nice in theory but not worth it.

Yeah. IMO, you don’t need to go very far into OS-level dependencies before it just makes more sense to use Docker. asdf et al can try to smooth the experience out all they want, and they certainly make things better, but unless your developer machines are REALLY standardised, it’s really building a castle on sand.

Whish there were some CLI to speed up this process actually. Just cd:ing into a folder should pull everything down for you to run iex/irb/node/etc as if it was native but running through the container.

wondering the same thing and is why I use Nix right now. I.e, works in prod / dev