Ditch your version manager

Nix supports building packages from multiple package sources. e.g. maybe you want an old version of some package which is only available in an older release of nixpkgs. It would be possible to use the older nixpkgs release to install that old package, and a newer nixpkgs release for the others. -- You even don't have to use the main nixpkgs repository.

> But I suppose this would amount to the user arranging the structure of their filesystem correctly so its one "system" per dir/folder.

Nix handles its filesystem arrangement for all of the "multiple different versions of some package" already. That's part of Nix's value proposition.

This also allows being able have packages available in your shell without having to 'pollute' the rest of the system is a neat dynamic, particularly with direnv.

> Theres clearly more to Nix than just setting up language environments, which I'm guessing is where its usefuleness really kicks in.

Depends how often you (want to) jump into fresh environments, but e.g. Nix allows being able to have a consistent set of programs installed quite easily.

I don't know if you realise that your post makes a poor case for that, and for imagined reproducibility of nix builds?

1. Direct quote from your post: "if you tried to follow this article step by step, you’ll have noticed that the versions of ruby and node you installed are probably slightly different from the ones above".

The "solution" for that is to dig through some commit hashes, and use those.

Commit hashes are not versions.

2. Your example points to a completely random version of a package

The previous issue already points to a random version, apparently, but this is further compounded by the fact that "ruby_2_6" and "nodejs-10_x" point to a random version that is available at the time.

To truly make the claim that nix allows reproducible builds, it needs to provide:

- a way to specify versions that don't depend on the commit hash of a "nixpck channel" whatever that is

- a way to actually properly pin package versions. Something that all package/dependency managers allow you to. If I want to pin ruby to exactly 2.6.7, for an actual reproducible build, what is nix' solution for that?

Second way is to override[1], in documentation they are showing how to change compilation parameters, but you can also use this to change version of dependencies or source tarball for the package. As you use Nix you will eventually need to do it as sometimes package was not updated, or perhaps you need to use older version, or enable compilation option.

Third way is to use overlay[2]. In previous way an existing package was modified. Overlay allows to completely replace or add a new one.

For example there is a tool called poetry2nix[3], which on the fly translates python poetry lock file to Nix so nix can build them. Nixpkgs includes it and generally is frequently updated, but maybe there was a fix yesterday that hadn't made it there yet and it fixes an important bug. You can fetch that repo independently and attach it to nixpkgs (or you can use it directly).

Nix also has upcoming feature flakes which to my understanding takes this to a new level. So you can easily compose multiple repos like this in your application.

> Theres clearly more to Nix than just setting up language environments, which I'm guessing is where its usefuleness really kicks in. But purely for lang env set up, I'm not sure I see a point over other tooling...

I use it this way and the killer feature for myself is that for a project all I need to have installed is Nix and I can have exact environment the dev used.

It's not mentioned often, but I think a demo of it would be the repo for Nix program[4]. Typically when you want to compile some open source program, after you check out the repo, a hunt starts for the building tools and libraries needed. With nix you just issue build command or enter build shell[5] and things just work with no errors (or at least I did not get them when trying it a while ago. Everything worked on first try).

[1] https://nixos.org/manual/nixpkgs/stable/#chap-overrides

[2] https://nixos.org/manual/nixpkgs/stable/#chap-overlays

[3] https://github.com/nix-community/poetry2nix

[4] https://github.com/nixos/nix

[5] https://hydra.nixos.org/build/153568733/download/1/manual/co...

It gets really complicated really fast, and things that "just work" with other packages managers and projects, because they are opinionated and linux-y, most of the time don't work well with Nix or have to be shoehorned into it.

It always feels like you're fighting against everything to get things into Nix that just weren't meant to be.

> The whole build system is pinned by on git commit. If it builds today, it will build tomorrow. No matter what.

If that commit is still available. This still doesn't answer the question of how I easily pin a version. The package versions in the post point to what amounts to a random package version.

And that's on top the fact that "if you tried to follow this article step by step, you’ll have noticed that the versions of ruby and node you installed are probably slightly different from the ones above"

> Nix stores each package in its own path.

This is a part that I like.