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

71–80 of 132 posts

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

#71

Post by bmitc »

king_geedorah wrote: post #42

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.

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

#72

Post by sgarland »

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

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#issuecomment-1383...

[1]: https://github.com/asdf-vm/asdf/pull/1441

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

#73

Post by appplication »

jdsalaro wrote: post #66
appplication wrote: post #55

Earlier quoted context omitted.

pyenv + pip tools is all one needs. Supposedly uv is gunning to be a drop in for both. I think there’s a good chance uv pulls it off and becomes defacto for this use case. I think it’s fair to see appeal in poetry, but ultimately the maintainers have created a culture that feels a bit too non-collaborative to outside ideas or use cases beyond what they more narrowly envisage. That said, my perspective may just be tai…

> pyenv + pip tools then you'd also need rbenv, nvm, etc. and pyenv can implode in marvelous ways.

I can’t speak to rbenv or npm, but IMO it’s better of use well known and canonical tools for each rather than a more unknown mega tool that wraps or replaces these.

pyenv isn’t perfect, and isn’t what I’d use for prod images, but for dev setup it’s relatively bulletproof and less issue-prone than any alternative I’ve seen.

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

#74

Post by ufmace »

karmakaze wrote: post #62

Out of curiosity, how many dev environments do folks use? Is this for reproducible environments shared by members of a team or company? For a single user with one development machine, simply having say a time-machine backup could be sufficient. I haven't had challenges for personal projects where details mattered. e.g. a Maven pom.xml, or Go modules/packages was sufficient for my needs. Historically I'd only cared ab…

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.

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

#76

Post by brabel »

jdsalaro wrote: post #65
karmakaze wrote: post #62

Out of curiosity, how many dev environments do folks use? Is this for reproducible environments shared by members of a team or company? For a single user with one development machine, simply having say a time-machine backup could be sufficient. I haven't had challenges for personal projects where details mattered. e.g. a Maven pom.xml, or Go modules/packages was sufficient for my needs. Historically I'd only cared ab…

> 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 company myself I would probably setup everything with Guix as I really like the way it works, more than Nix (though only because I prefer Lisp config files and because Guix doesn't suffer from any polemics like the flake soap opera).

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

#77

Post by brabel »

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?

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.

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

#78

Post by brabel »

iainmerrick wrote: post #64
lexlash wrote: post #50

Having been down this path - asdf didn’t go far enough in creating reproducible/sealed environments, the quality of the plugins per language varied dramatically, shims made a lot of assumptions about how tools will be used, and you can expect to throw asdf away the moment you need to deploy and then have to build something else. I don’t like Nix but I haven’t found anything else that scales along those critical requi…

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

Every language has a tool like NPM (actually, nvm in the context of this discussion) these days. The problems tools like Nix solves (and arguably, Asdf) is that instead of learning each language's tools you only need to learn one tool that manages multiple languages and system dependencies.

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

#79

Post by brabel »

jdsalaro wrote: post #33
doctorraags wrote: post #24

Is it just me that never even wants to get to the problems that asdf attempts to solve? That example in the article of managing multiple python 2.7 versions sounds like a horror story.

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

You shouldn't need asdf to work with JVM stuff. I would suggest learning how to use SDKMAN: https://sdkman.io/

It will manage the JDK for you. Usage is basically this:

   # Install a JDK, that version is now default
   sdk install java 
   # Another one, it asks if you want to change the default
   sdk install java 
   # List available and installed versions
   sdk list java
   # Change which one you're using in this shell
   sdk use java
That's all.

You can also manage Gradle/Maven installations with SDKMAN, but that's not necessary, usually, because most JVM projects include a "wrapper" script which downloads the needed Maven/Gradle version for you.

This works regardless of whether your project also needs Kotlin/Groovy etc. as those are just managed by Gradle/Maven (the only exception I can think of is if you use Kotlin Multiplatform as that will depend on the platform dependencies as well).

So once you know SDKMAN, you can manage any JVM-based project with just this:

    sdk use java 
    ./gradlew build # or ./mvnw package
If you need to do anything else, you should complain to the project authors as this is really all you should need!

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

#80

Post by lawik »

karmakaze wrote: post #62

Out of curiosity, how many dev environments do folks use? Is this for reproducible environments shared by members of a team or company? For a single user with one development machine, simply having say a time-machine backup could be sufficient. I haven't had challenges for personal projects where details mattered. e.g. a Maven pom.xml, or Go modules/packages was sufficient for my needs. Historically I'd only cared ab…

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.

Post reply on HN