Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Install Asdf: One Runtime Manager to Rule All Dev Environments

jdsalaro.com

Post reply on HN
Print view View original

101–110 of 132 posts

Re: Install Asdf: One Runtime Manager to Rule All Dev Environments

#101

Post by codethief »

jdsalaro wrote: post #17
matsemann wrote: post #9

Because of the insanity of python versions, paths, wheels etc and tiredness of spending time getting poetry install to work for project X due to also needing a full rust and c++ toolchain for some dependency etc.. .. I run everything for a project in a container. Each project then matches perfectly the container actually used in production, so if it works there, it also works on my machine. I just volume mount the pr…

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.

Not OP but I've been using asdf and Poetry together and have been pretty happy with my setup. What issues were you experiencing?

Re: Install Asdf: One Runtime Manager to Rule All Dev Environments

#102

Post by RulerOf »

karmakaze wrote: post #98
ufmace wrote: post #74

Earlier quoted context omitted.

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 dif…

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.

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

Re: Install Asdf: One Runtime Manager to Rule All Dev Environments

#103

Post by FireInsight »

vorticalbox wrote: post #99

I loved asdf but since moving to immutable fedora I've started loving distrobox more. By giving each box it's own home folder vscode in each has only the extensions for that language. E.g I don't have any python extensions in my nodejs box. Been working like this for a couple of weeks now and it's pretty good. If I end up breaking a box I can simply delete it and start over.

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.

Re: Install Asdf: One Runtime Manager to Rule All Dev Environments

#104

Post by thiht »

hk1337 wrote: post #63
thedookmaster wrote: post #2

I've used asdf for years, but recently switched to https://github.com/jdx/mise It's a drop-in replacement for asdf, but I prefer some of the nice features it has to offer. See: https://mise.jdx.dev/dev-tools/comparison-to-asdf.html

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

It's normal to build new stuff based on the experience we got from what came before. If you like asdf, use asdf, there's nothing wrong with using it, and there's nothing wrong with wanting something "better" (depending on what "better" means for the user)

Re: Install Asdf: One Runtime Manager to Rule All Dev Environments

#105

Post by juunpp »

lispm wrote: post #83
brabel wrote: post #77

Earlier quoted context omitted.

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.

And the possibility of using "Google" to check for name collisions seems not to be known...

The possibility of existence of a "programmer" that is completely oblivious to Common Lisp is the really interesting phenomenon to ponder here. But hey, at least the article links back to Hacker News, Mastodon and Reddit so that we can all revel in ignorance. Surprised there is no Discord.

Re: Install Asdf: One Runtime Manager to Rule All Dev Environments

#107

Post by out-of-ideas »

000ooo000 wrote: post #38
noobermin wrote: post #10

Wait, not only is it called asdf leading to confusion, it literally is also a package manager of sorts just like the original asdf??? I just tried googling it having not really used CL in a while, and apparently it was seo'd to the top of google results too?

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.

agreed, but i know firsthand words are hard, and names are more specific words and can be very hard (especially for developers) - esp with shorter names ,and will have a higher chance of a name collision

Re: Install Asdf: One Runtime Manager to Rule All Dev Environments

#108

Post by jdxcode »

chem83 wrote: post #61
oakesm9 wrote: post #5

Earlier quoted context omitted.

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

mise borrows the plugins from asdf, which also makes it non-cross platform. Interesting discussion on this topic on their GitHub: https://github.com/jdx/mise/discussions/66 Solutions considered include adopting the vfox plugin system or transpiling all asdf plugins to ShellJs. Now I know that vfox exists.

I made some progress on windows last week! I'm working on making it so vfox plugins can be used as the "default" backend instead of asdf which will be a prerequisite for windows support. Step 1 is being able to run vfox plugins inside of rust which I got pretty far on: https://github.com/jdx/vfox.rs

It'll be a long road ahead and I could certainly use some help if anyone out there is interested in moving it forward. That said, vfox is a really great project and they are targeting windows specifically. Windows will probably always be second in the mise ecosystem (because I don't use it) but my hope is I can get at least a baseline of support which would help teams that have occasional windows contributors.

Re: Install Asdf: One Runtime Manager to Rule All Dev Environments

#109

Post by jdxcode »

jdsalaro wrote: post #13
roylez wrote: post #7

Earlier quoted context omitted.

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 was only vaguely aware of rtx, but after discussing this post at length with people online they've made me aware of the rebranding and the general capabilities of mise. It sure is great, it is! However, like you, I tend to prefer minimalistic and predictable tools. That's why I decided to add the small comment in the discussion section of the post, to be fair but also kind of clear that bloating the runtime manager…

Mise does a lot of things and I don't buy into the unix philosophy so you may not like it (which is totally fine btw, my goal is not at all for everyone to love it).

That said, I think if you thought about _why_ you like minimalistic and predictable tools you may find that mise solves the underlying reasons for that. My whole thing is about augmenting your environment and not replacing it. This is generally where I contrast mise with tools like nix and docker but I thought it was worth calling out.

I think people like mise because they can use it for just setting some env vars, installing a few npm packages globally, having an easy way to synchronize tool versions between local dev and CI/CD. You can use it for any one of those things and it slots right in wherever you are—whether that's inside VSCode, ssh'ed into a remote machine, in a github action, or inside a docker container in a k8s fleet.

Yeah mise is capable of a lot of different things, but the important thing is that it doesn't force you to change anything _else_ about your setup.

Re: Install Asdf: One Runtime Manager to Rule All Dev Environments

#110

Post by jdxcode »

johnathon023 wrote: post #22
jdsalaro wrote: post #13

Earlier quoted context omitted.

I was only vaguely aware of rtx, but after discussing this post at length with people online they've made me aware of the rebranding and the general capabilities of mise. It sure is great, it is! However, like you, I tend to prefer minimalistic and predictable tools. That's why I decided to add the small comment in the discussion section of the post, to be fair but also kind of clear that bloating the runtime manager…

Mise’s #1 objective is to be a really great tool manager, just like ASDF, but way faster and smarter. However, it turns out that a tool that needs to be extremely CWD-aware also makes a great .env tool and task runner. I was also a little skeptical, but it’s actually super super useful. Especially because it’s easy to convince team members to install it for the tools, they get the rest for free with easy syntax.

You pretty much nailed it here. Env vars and tasks were kind of a happy accident—I implemented both inside of a day. (different days of course) Just because I realized I had all the building blocks to make them possible already, just needed to arrange them in a different way and they just appeared.

In the future though I see tasks as being the headline for mise over tools. That's a ways out, certainly more than a year, but the thing about tasks is they don't suffer from the drawbacks that both PATH and shims have for putting your tools in the right place. In my personal use of mise I don't actually like using `mise activate` whatsoever. The problem is just that I can't yet do everything with tasks easily enough. Tasks need to get to a point where they're so easy you won't want to bother with having tools in your shell.

Though who knows. I may be off my rocker on that one. I certainly get things wrong as much, if not more, than I get them right.

Post reply on HN