You can hardcode a specific version of nixpkgs, instead of a branch. With the new Nix CLI & flakes enabled you can do something like this:

nix run "github:NixOS/nixpkgs/b4372c4924d9182034066c823df76d6eaf1f4ec4#cowsay" "moo mooooooo"

That's the commit I'm seeing for nixos-23.11 today, and it should still give you that exact version of cowsay years from now.

Of course, the better option is to make a dev shell with flakes. Flakes come with a lockfile builtin that accomplishes the same effect, and there's no problems having different projects on different lockfiles/versions. It's a bit more work to learn, the Zero to Nix tutorials are pretty decent at teaching and come with examples though (ultimately most things are ~30 lines of boilerplate and a list of packages that you want).

Use this! nvs --install ruby@2 (I'd attach the gif but lemm.ee doesn't support images)

I had your exact complaint. And it only took me 3 years and hundreds of hours of learning nix to make that tool 😅

Btw, while it solves version search, fair warning you're going to immediately run into other usability problems. I use nix every day but I don't gaslight people into thinking it's usable.

I only started diving into nix this year so I'm still learning, but yeah, I'm pretty sure the lack of granular versioning is a common pain point with nixpkgs. I'd suggest checking out flakes if you haven't already, but be warned, it gets hairy lol

If you're using the Debian "no Frankenstein" approach, you're limited to what is packaged, but if you do your own thing, you can have it build/install whatever you want.

Rtx on/off meme template;

"Off" is a greyscale picture of metacat struggling with manual dependencies. Possibly combined with "Isn't there a better way?" from ye olde shopping channel ads.

"On" Is a HDR image of a smiling metacat having no such issues. In the background a rainbow can be seen over a flowery garden, in which people are holding hands with rabbits frolicking in the grass.

Yeah yeah, I know, I'll go to bed now...

Awesome! You bet, glad to hear it worked out.

What do you mean? I containerize my tools, and write a docker file to install everything. The dockerfile is just something like:

FROM ubuntu:22.04

RUN apt-get update &&
apt-get install -y helm pluto kubeval etc

How is that gross?

It has random side effects that break cli tools (tools that are not even installed with ASDF)

The more versions you add, the slower it gets. And it can get really slow (that issue was opened in 2018, and it is fixable).

It's got many "well it works on my machine" problems. And the author said that's a "wontfix" design choice. That's fine for the author, it's FOSS. But it means my workflow is going to randomly break and I just can't have that when it's my job.

Pkgx, Devbox and nix avoid all these things.

I'm not who you asked, and not a user of pkgx, but one of the reasons I prefer rtx (which supports asdf plugins) to asdf is that by default it doesn't use shims, but updates the PATH instead.

So for example, running which python will show me a clearly versioned python executable path, rather than a mysterious shim that represents a different realpath at different times.

Tbh, I think my issues are less with rtx itself and more the plugins I'm using and the constraints imposed by the asdf plugin structure.

I ran into issues where poorly written plugins could fail to install, but rtx wouldn't recognise the issue and if I re-ran "rtx install" a second time it would tell me that the runtimes were all up to date. I'll see if I can put together a GitHub issue describing it in more detail.

It'd be nice if there was a simple way to reference a local directory as a plugin for a project rather than having to publish a separate git repo.

Generally it's a really well built tool and the docs are excellent, my complaints are nitpicks