Live data from Hacker News

Install Asdf: One Runtime Manager to Rule All Dev Environments

jdsalaro.com

111–120 of 132 posts

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

#111
post #63

Earlier quoted context omitted.

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

The main issue most people have with asdf is that it’s annoyingly slow. Not unusably so, but just enough that it’s irritating. I identified [0] the source for much of it (sub-shells and pipes) and began a PR [1], but became bogged down with BATS testing, and then found mise / rtx, so kind of lost interest. Sorry. You can always implement these if you’d like. [0]: https://github.com/asdf-vm/asdf/issues/290#issuecommen…

[dead]

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

#112
post #85

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. From there I just always work in virtual environments. This doesn't seem to have created any major problems for me, so something like asdf doesn't feel necessary. Is there something serious that I've missed or is this just a case o…

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.

> How do you update the list of installed python versions?

There are only three for me and I don't have a reason for more in the near future, so I just remember.

> Generally asdf shines when you need more than one system installed

Makes a little more sense to me.

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

#113
post #71

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. From there I just always work in virtual environments. This doesn't seem to have created any major problems for me, so something like asdf doesn't feel necessary. Is there something serious that I've missed or is this just a case o…

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

Does asdf automatically pull in its own copies of libraries for relevant functionality? For example I needed headers for readline in order to get that going on my compiled interpreters. If it avoids that then that could be a reason to use one over the other at least on new systems.

Edit: Decided to peruse the code for the python asdf plugin myself and it seems to just use pyenv under the hood anyway, so I guess it's not really a question of what asdf does anyway.

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

#114
post #76

Earlier quoted context omitted.

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

IMHO the solution for the problem of devs in the same company having different environments is not Adsf and its competitors like Mise, but things like Nix/Guix and Docker. At work, because everyone uses Mac, we ended up using Kandji to achieve the same thing: everyone has the same tools and environments, but that is only if you already have to use that due to security audits and stuff like that. If I had a small comp…

I just use small VMs. I use Vim as my code editor and just ssh into it. No difference, latency wise. if I was on Linux, I'd use LXC containers.

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

#115
post #51

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. From there I just always work in virtual environments. This doesn't seem to have created any major problems for me, so something like asdf doesn't feel necessary. Is there something serious that I've missed or is this just a case o…

If you have a requirement for multiple, specific Python versions, why not just use pyenv? https://github.com/pyenv/pyenv

That's not an unreasonable question. I don't really have a good answer to it outside of I found building and installing the couple that I needed myself to be fine and don't mind invoking as `python3.11` or what have you, since it's only different when I'm initialising my venvs.

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

#116
post #59

Earlier quoted context omitted.

Dont we have VSCode Dev Containers? That works impressively well

We do, and they are pretty cool but incredible limited. For one, you have to limit yourself to vscode and/or other IDEs with this capability - which ought to be a dealbreaker right there. But then you still have issues around syncing permissions and paths inside+outside the environment. And that all your other windows have a different view into your project. That alone is another dealbreaker (which you can bandaid, b…

Why not VMs? With the kind of computers dev have, I'd think it be trivial to have a VM dedicated to one project (unless you're doing gpu). This means I don't have tooling associated to projects (databases, webserver) populating the main env, only personal stuff.

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

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

Actually no, it manages the versions of the languages themselves, but doesn't interact with their package managers at all. The .tool-versions file it uses to mark the current version could be thought of as a lock file as well. It replaces (for Ruby) rbenv/rvm, not rubygems. Rustup, not Cargo, etc.

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

#119
post #77

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?

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.

Came here to ask that. I've used the CL ASDF for decades now and have been confused more than once to run across docs for this one instead.

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

#120
post #30

I've had nothing but problems with asdf and nodejs and globally installed tools like yarn reporting "Cannot find node". Perhaps global tools cannot be compatible I don't know; asdf reshim doesn't often fix it.

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?

So that in any directory you can type ``? asdf Node installs aren't like Python virtual environments; they're centrally installed and one Node version (and its packages) is shared across all diretories that want it + global tools.
Post reply on HN