[zaSmilingIdiot]

Looks interesting enough... But how does one solve the issue of security level updates for some dependency language? Or when a particular version of some application reaches EOL and is no longer maintained, or theres some functionality in a newer version of Nodejs|Ruby|etc thats needed?

From what I understand this would require an update to the Nix version that supports it... but that also potentially means bumping other environmental versions as well, which might not be desired. But I suppose this would amount to the user arranging the structure of their filesystem correctly so its one "system" per dir/folder... Or is there a better way to cater to this? And I suppose this still means that the node modules, gems, etc that are being used then anyway also need to be updated after this accordingly.

From my limited understanding of Nix, it seems interesting, and the article was actually useful to me. But I cant seem to shake the feeling that this is another packaging abstraction like others before it, and while it seems like a better variant, its not much different to having X, Y and Z listed as requirements and then letting the dev go off and install such dependencies on their system, in the way that they best know how. Juniors or those new to a specific environment might not know the ecosystem so well so as to know to use rbenv or nvm or whatever, but I'm not sure how Nix solves this issue differently than one of the specific tools its replacing.

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

[rgoulter]

> But how does one solve the issue of security level updates for some dependency language? Or when a particular version of some application reaches EOL and is no longer maintained, or theres some functionality in a newer version of Nodejs|Ruby|etc thats needed?

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.

[takeda]

There are multiple ways of doing it. The obvious one (updating nixpkgs) you already mentioned.

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

[aidenn0]

4th way is to just package it yourself and use pkgs.callPackage to add it. Overlays are nice for the whole system or if you're still using nix-env, but I find it more clear to use callPackage directly when I'm explicitly building an environment.

[takeda]

Good point, I forgot about that one.