Comment by happens | Hacker News Reader

Comment by happens | Hacker News Reader

I've written a rust version of asdf over the last few months, both as an exercise and to fix a few issues I've been having with it - like noticeably slower tool startup times due to the shims resolving the version (my version basically works like direnv under the hood and hooks into the shell directly) and me just wanting a single "use" command which installs a plugin, downloads the requested version and sets it as active. It works very well and I've been daily driving it for a while.

Having the ecosystem of asdf plugins which are basically just shell scripts has been a huge boon. It's been a breeze to work with, and most of the plugins are well written.

Now, I've been contemplating switching to NixOS, but most version managers don't work at all with it due to dynamic linking. I absolutely love the idea of NixOS, but this has really bummed me out. I feel like the nix language is still a little clunky for general use, so as long as there is not a straightforward solution like having a tool-versions file I'm really hesitant to make the full switch.

There was a recent post about asdf performance from the maintainer that is quite illuminating:

http://stratus3d.com/blog/2022/08/11/asdf-performance/

I feel like they're just hitting the limits of a bash+shims based approach. I understand why they've done it, but in the end an implementation in a compiled language will beat that approach most of the time. There are issues since a shell hook will only work as long as you're, well, using a (supported) shell.

However, it's surprising to hear that they've been focusing on UX. The fact that you have to manually install a plugin, then install a version, and then finally set it, without the tool suggesting any of those steps to you when you forgot one, really makes the tool annoying to use when switching versions a lot.

I don’t agree.

As a proof of concept I wrote a Fish native version of the function that figures out what local version of a tool to use I do actually use it to show the currently selected version in my shell prompt. The asdf version was unusable in a shell prompt.

It goes through the parent directory structure up until the top level root directory and finds the first .tool-versions file and parses out the version of a specific tool.

The asdf native shim takes ~100 ms in Bash (no idea if it can be optimized, but I assume so). My Fish version takes ~1 ms.

I'm not familiar with the performance characteristics of fish, so I can't really speak to that. I only remember that the developers of asdf themselves had problems with resolver/shim performance and even temporarily implemented only that specific part as a go executable, and projects like asdf-direnv also try to work around the problem.

I don't use NixOS myself, but have Nix installed on my Mac, and it seems to provide all functionality of package or version managers I needed.

I think though it is more complex because it is a programming language that provides this functionality instead of purpose build tool like asdf.

For my needs I created a framework for development: https://github.com/takeda/nix-cde to avoid cruft of including the same things over and over in my projects.

Interesting, thanks for sharing! I'll have a look over the weekend.

I first started using nix thinking of it like a version manager also, but that’s not what it is, and thinking of it that way will only bring pain.

Nix is a package manager (like apt or whatever), and like package managers, it works with a set of vetted, decently verified package versions (NixOS releases). Mostly this is fine. It’s easy to use nix stable for most stuff and nix-unstable for anything where you need newer stuff. You can then configure “overlays” to the set of packages where you specify how to build particular versions where you need it.

It took me a long time to make the mental shift from nix being something like pip or npm or asdf or pyenv or whatever to thinking of it like a true linux distribution’s package manager, but it helped everything to click once I did

Thanks, that's a helpful perspective. I saw that there's also specific packages for things like node versions, so that might be an alternative to writing overlays in some cases. I'm just concerned about packages without any support being extremely cumbersome to install, since it's hard to run regular binaries.

Thank you for sharing - I've written my own "version" of asdf in Bash too, and I'm getting to the point where I would like to write some portions in Rust.

Does qwer support per-directory, local versions of plugins? I'm finding that that's difficult to do without shims...

Yes it does! It uses the pre-cmd hook of shells and sets the environment, similar to how direnv works.

Cool I see - I override cd, but now I'm pondering if I should change approach. But I guess what I was really asking is how you do it in non-interactive mode?

> noticeably slower tool startup times due to the shims resolving the version

I migrated to asdf from nvm because of nvm's very slow startup time. I haven't noticed excessive startup time on asdf yet. I wonder what's the issue with your asdf installation.

Would you mind sharing your tool?

You can find it at https://github.com/happenslol/qwer . Be warned though, it's heavily lacking in documentation and polish, although all core features are working. I've just added a bit of info to the Readme, hit me up if you have any questions.

Appreciated. Will try next weekend.

This is really cool! You're pretty much solving all the issues I've had with asdf! Keep up the great work!

This looks really promising. I love seeing these tools written in languages other than the thing they're targeting.

As an example I use fnm (https://github.com/Schniz/fnm) for managing JavaScript versions. It runs so fast (compared to nvm) I'm inclined to think something went wrong and it silently failed, but it never does!

Reply on news.ycombinator.com