[klodolph]

I’m using Nix for development and generally I agree.

The first catch is that I want to be able to update my system on a regular basis, and keep using exactly the same dependencies in my project after an update. Maybe I’m in the middle of working on a change.

The second catch is that sometimes my development environment is really weird, and the packages I need aren’t in Debian. At least, not the versions I want. Nix can handle cross-compilation environments and you can use it for embedded development. You stick your entire development toolchain (arm-none-eabi-gcc, whatever) inside your development environment.

> Why would I want to roll a system back to an (definitely insecure) state of a few months ago?

Periodically, I want to update everything in my development environment to the latest version of everything. Sometimes, something will break. Maybe a new version of GCC reveals previously undiscovered bugs in my code. Maybe a function gets removed from a library (I’ve seen it happen). In Nix, it’s pretty easy to pin my entire development environment to an old version, while I’m still updating the rest of my system. I can also get the same environment on either Linux or macOS with relatively minimal hassle (with the note that I’ve run into several packages that just don’t run on macOS, which required me to make “fixed” versions).

Also keep in mind when I say “Nix”, I’m talking about nixpkgs. I’m not using NixOS and I just don’t care about NixOS.

Nix also has its pain points. I think of it as being like a coarse-grained Bazel with a ton of packages.

[nyarlathotep_]

My Nix experience is limited, so forgive my ignorance here, but is it possible to create a development environment for an "older" project as well?

Say I need some 3.20 version of CMake and gcc 9/whatever or something--i assume such a thing is possible, but I've not seen a simple way to "pin versions" of things the way you would in say a language's package manager.

[klodolph]

My Nix experience is pretty limited, too. Nix is not great at pinning to specific versions.

If your older project was made in Nix, it’s no problem. You just check out the old copy of the project and you automatically get the old copy of the dependencies.

If your old project needs some specific major version of GCC, going back to like 4.8, there are specific packages in Nix. You just add “gcc48” to your dependencies and you get GCC 4.8. You still get newer versions of e.g. binutils.

If your old project needs a specific version of CMake, I know two ways to get that, but they’re a little ugly.

First method is to import an old <nixpkgs> containing the right version of CMake, and then import that into your environment. You search through Git history of the nixpkgs repository until you find one with the correct version. Yes, this sounds awful. It’s not that bad. I’m not sure how to do this with flakes.

You can also copy the CMake derivation into your project and modify it to compile & build the version of CMake you like. This is the approach I would normally use, most of the time.

There may be easier ways to do this. I’m not sure.

[nyarlathotep_]

Thanks, that clears up my understanding. I'd suspected it was something along those lines.

[lexlash]

https://www.nixhub.io/ - and I’ve seen others - make the searching easy. It’s odd to me that I rely so much on web based tools (like search.nixos.org!) to look up nixpkgs details for my commandline but eh.

For a flake, you’d specify an input of that specific revision of nixpkgs and then refer to your CMake dependency with respect to that input. You may end up with - by design - a lot of duplicated dependencies, but it’d work.

https://blog.mplanchard.com/posts/installing-a-specific-vers... is a nice writeup (not mine) with examples of a few different ways to do this in flakes and not-flakes.

[klodolph]

Yeah, relying on `search.nixos.org` is a little weird. Package discovery overall is a little weird… I think I usually do it through nix repl.