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

Asdf – An Extendable Version Manager

asdf-vm.com

Post reply on HN
Print view View original

71–80 of 100 posts

Re: Asdf – An Extendable Version Manager

#71

Post by pensatoio »

sergiotapia wrote: post #5

asdf makes my life so much easier seriously, it's amazing. Try it! I have a .tool-versions file in code repo that lists what I need for a project. elixir 1.2.3 erlang 1.2.3 nodejs 1.2.3 Whenever I `cd` into the folder, asdf automatically uses the right versions for me. I don't have to worry about anything. Razer sharp scalpel of a tool.

:heavyplus:

.tool-versions means everyone on the team knows which version(s) to use for a project, for anything outside of docker. Auto-install is an awesome feature, too.

Re: Asdf – An Extendable Version Manager

#72

Post by meatcar »

philsnow wrote: post #59
nikolay wrote: post #7

I've been using it and has contributed to it, but I wish it supported out of the box GitHub-based release binaries as 90% of my code for different vendors was relatively the same, so, instead of having multiple identical repositories, I created one, which uses introspection [0]. I wish this was available out of the box to handle literary 90% of the tools. Also, I typically pair it with direnv [1] for even more magic.…

Seeing all the love for direnv makes me feel like I'm the only one taking crazy pills. Direnv breaks referential transparency of the shell. I heavily use my shell history to riff on commandlines I've entered in the past. If direnv is in the mix, my shell pipelines sometimes have to have `cd` in them, often in subshells because that works better for me than pushd/popd. pyenv/rbenv/asdf do the same thing, but you can h…

You can just not hook direnv into your shell, and use `direnv exec` kind of like pipx.

Tools like asdf, direnv, nix-shell, etc. just encapsulate the environment and help set up some guarantees. The referential transparency of shells is something that these tools help enforce, if anything.

I agree that frequent jumping between the fragmented environments is pain point in software development these days. That's due to a lack of tooling to support the new workflow, in my opinion. I hope enough people feel this pain that we see some solutions.

Having an expressive shell like https://starship.rs helps keep you oriented as a sort of HUD. Nix is definitely a life-saver, but you can probably roll your own nix-a-likes. Encapsulate all the "global" precious tools, hardening them against changes in the "local" shell environment. Whether through wrapper scripts, containerization, or what have you, the building blocks are there, the "best practices" are still being created.

Re: Asdf – An Extendable Version Manager

#74

Post by jaxn »

pensatoio wrote: post #70
jaxn wrote: post #61

Does anyone know a good way for asdf to inform which versions are installed in container? I feel like I keep having to hack together ways to do the same thing when building containers for apps build with asdf. (Github actions, dockerfile, heroku, etc)

I don't think using asdf in your container builds is a good idea tbh. You should pin your container to a specific version, or perhaps set the base image version by parsing the .tool-version file.

Yeah, I didn't write that clearly.

We have this great .tool-versions file defining the version of ruby, node, yarn, etc. It's great.

Then we setup github actions to run linting/tests/etc, and we have to define those same versions either explicitly in the .yml or via some hacky shell commands to pull version info into a RUN curl...

It would be great if there was a little more standardization around language versions. Or maybe there is a secret convention that I just haven't heard of yet.

Re: Asdf – An Extendable Version Manager

#75

Post by desmap »

desmap wrote: post #67

Tried asdf few months ago but couldn't get warm with it. Went back to nvm for node and just venv/ for Python. Anyone went back too and if yes, why? Thinking of giving it another try.

FWIW and a note to myself before I check it out a third time:

I just checked it a second time and recall now what was turning me off: I found the installation of the node plugin and node super tedious and too much overhead[1], it's just once but yeah, didn't like the the UX (eg reshim), then asdf always forgot my current node version and finally, I was missing a quick ls command for checking out installed node versions and versions/lts-versions available remotely (nvm ls and ls-remote ) without having to checkout the node website or repo.

I cannot speak for other languages but I found it for node rather a bigger step back and for stuff like Mongo—it's in their plugins!—I just use Docker, IDK but asdf feels just wrong for things like Mongo. I usually use node also from the node Docker image and have node versions only locally installed for stuff like coc-vim or when quickly needing the node REPL but anything serious runs in a container with a volume mapped to the project folder.

So, I guess it's rather for languages that do not have a proper version manager and/or folks not into containerization.

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

Re: Asdf – An Extendable Version Manager

#76

Post by darkblackcorner »

nine_k wrote: post #62
nikolay wrote: post #7

I've been using it and has contributed to it, but I wish it supported out of the box GitHub-based release binaries as 90% of my code for different vendors was relatively the same, so, instead of having multiple identical repositories, I created one, which uses introspection [0]. I wish this was available out of the box to handle literary 90% of the tools. Also, I typically pair it with direnv [1] for even more magic.…

Magic. This is not what I'd like to see around my code and my systems. I'd prefer everything about them to be transparent and explainable. (My favorite worth-1000-words picture about that is e.g. here: http://www.tshirtvortex.net/free-magic/ )

That's a brilliant T XD

Re: Asdf – An Extendable Version Manager

#77

Post by leipert »

We use it at GitLab since a few months in order to manage our development toolchain [0]. Before we had people using rvm, rbenv, nvm, homebrew, system packages and everything in between. Supporting our engineers and non-engineers has been a lot easier since asdf, and the whole version manager related issues calmed down a bit.

The only thing I miss from homebrew is the pre-compiled stuff like e.g. Postgres or redis

[0]: https://gitlab.com/gitlab-org/gitlab-development-kit/-/merge...

Re: Asdf – An Extendable Version Manager

#78

Post by b0afc375b5 »

whitepoplar wrote: post #65
vlunkr wrote: post #49

We started using this for elixir/erlang and quickly replaced all the other version managers company-wide. The only issue we've really had is that sometimes people don't understand reshim and when they need to do it.

When does one need to use reshim?

In my experience, after installing a version of nodejs, whenever I install a global npm package I have to manually reshim (`asdf reshim nodejs`) so that bash will be able to locate it in $PATH.

Re: Asdf – An Extendable Version Manager

#79

Post by nathell »

samatman wrote: post #66
nescioquid wrote: post #4

Not the ASDF ( https://common-lisp.net/project/asdf/ ) I was expecting.

Yeah I'm not usually a "hey there's another project with that name" kinda guy but, build manager and version manager? Isn't there some other part of the keyboard they could have mashed?

Sure there is. One of the proposed successors to ASDF the Common Lisp package manager is XCVB (https://common-lisp.net/project/xcvb/), the eXtensible Component Verifier and Builder.
Post reply on HN