happens

Nice! I tried something similar at github.com/happenslol/qwer, I'll look at yours to see what you did differently :-)

So, this syncs through a hosted server somewhere? Can I host my own? That information should be front and center imo, I didn't see in anywhere in the Readme.

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.

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.

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

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

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.

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

Thanks, that's very insightful. I feel like especially in larger projects, going for a monorepo approach where the integration tests are just another package that runs on the entire repo makes what you're doing very powerful.

How do you write your tests? I love go, but when it comes to testing I'm torn between having a more standardized setup with BDD tests (but worse ergonomics), or completely free-form tests with just a simple assertion library (but better ergonomics).