| 10 Jun 2023 |
 @woshilapin:matrix.org | Hi there, I'm currently discovering the wonderful world of Nix since less than a week, and I'm trying to write my first flake: very simple project, only need Terraform at this point. However, my CI is using an older version of Terraform, so I'd like to have my local development environment use the same version. But I couldn't find an easy way to choose the Terraform version. The only way I found was to find an old enough commit on NixOS/nixpkgs to refer to in my flake. Is there something easier I missed? | 07:08:28 |
 emily | yeah, nixpkgs is a monorepo where all package versions are built and work together. some packages have multiple major versions explicitly packaged (things like OpenSSL or PostgreSQL or whatever where there's long transition periods or complex migration procedures), but otherwise it's one version per commit. your options are to use an old NixOS release branch that has the right version (which has the advantage of, if it's a new enough release, getting you security updates etc.), or pin a specific commit | 07:13:05 |
| emily | you can have multiple nixpkgs inputs, though, pointed at different commits, so you don't have to use old versions of everything if that's inconvenient | 07:13:30 |
| emily | https://search.nixos.org/packages lets you look up the package versions to see if there's a maintained stable branch with the one you're looking for | 07:14:37 |
| @woshilapin:matrix.org | ok, thanks for confirming a bunch of stuff and also giving some new inputs (the aspect mono-repo, everything is built and work together). All of it make sense, but I guess I needed someone to explicitely tell me | 07:15:08 |
| @woshilapin:matrix.org | Thanks for the search link above, I already found out about it. However, I don't see where I can look for all available versions for a package 🤔 | 07:16:46 |
| emily | it's a big part of the value-add (since you get things like atomic updates of package sets where you're never mixing potentially incompatible versions, and NixOS has automated integration testing QA for many areas of the system), but it does mean things are a little more complicated when you do need an old version of some random package or to mix and max | 07:16:55 |
| emily | ah I just meant toggling the "Channel" option to see the versions, if you want to see all the versions at a glance then I don't know if there's a specific tool for it (I guess you could use repology.org) | 07:18:03 |
| emily | there's only three branches you'd ideally want to use though, since if you have to track anything older than that it's "no security updates" territory | 07:18:53 |
| @woshilapin:matrix.org | For now, I just searched for a PR in the nixpkgs Github repositories, looking for the package name and version I was looking for... then took a parent commit of this merged PR 🤷 | 07:19:33 |
| @woshilapin:matrix.org | In reply to @emilazy:matrix.org
there's only three branches you'd ideally want to use though, since if you have to track anything older than that it's "no security updates" territory Given that fact, that means I will never be sure to find exactly the version I'm looking for a package, and getting the security updates with it, am I right? | 07:21:11 |
| @woshilapin:matrix.org | In any case, thank you very much emily for your thorough answers, it helped a lot 😄 | 07:23:27 |
| emily | yeah, maintaining multiple branches of nixpkgs is effort enough already, the exponential explosion of ensuring every version of every package works with all updated package versions would just be too much for any human organization :) | 07:24:38 |
| @woshilapin:matrix.org | Indeed, makes sense 🤯 | 07:24:56 |
| emily | however, if you really need to, you can vendor an old version of a package definition in your own tree, if you need newer dependencies and the derivation still works with them, and you're happy to have it built locally | 07:25:18 |
| @woshilapin:matrix.org | Ouch, I'm gonna take some more time to digest that 😅 | 07:26:34 |
| emily | tl;dr you can always copy-paste from old nixpkgs as a last resort :P | 07:30:31 |
| 11 Jun 2023 |
| @woshilapin:matrix.org | Still trying to make my first flake and I'm now having problem understand the check concept. I found at least 2 ways of launching it nix flake check or nix develop --check but I'm not sure they're the same. And in flake.nix, I found out about the checks.x86_64-linux.default outputs, but I also understand there is a checkPhase in any stdenv.mkdDerivation (so there might be one in outputs.checks but also in packages.checks?). I'm relatively lost at this point with all of this. Ideally, I'd like to be able to run terraform validate (which validates the entire terraform project, sort of lint). | 15:25:32 |
| @woshilapin:matrix.org | (it's also very possible I'm totally misusing these tools, and if it's the case, please also tell, I'm interested 😄 ) | 15:26:12 |
| 13 Jun 2023 |
|  Jake Hillion joined the room. | 13:04:00 |
|  @federicodschonborn:matrix.org changed their profile picture. | 20:55:34 |
| 14 Jun 2023 |
 elonsroadster | I'm probably missing some obvious documentation on this, but are there any CLEAR explanations of the follows mechanism of nix flakes.
My flake.lock files consistently seem to accumulate like 20 different versions of nixpkgs, and my hope would be that they would all be pointing at the same underlying nixpkgs.
Is there a principled way to solve this issue? | 00:15:03 |
 kenji | In reply to @elonsroadster:matrix.org
I'm probably missing some obvious documentation on this, but are there any CLEAR explanations of the follows mechanism of nix flakes.
My flake.lock files consistently seem to accumulate like 20 different versions of nixpkgs, and my hope would be that they would all be pointing at the same underlying nixpkgs.
Is there a principled way to solve this issue? Nix flake Info should show you which input relies on which inputs. | 00:22:04 |
| elonsroadster | Thanks a-kenji super helpful. Okay looking at it now, the problem is pretty deep down there in a transitive dependency. Is the right way to do this to make the dependency explicit and then explicitly set all the follows? | 00:24:12 |
| kenji | If you have an input called nixpkgs and an input that is called rust-overlay that itself has an input called nixpkgs, then you can pass it in the following way: rust-overlay.inputs.nixpkgs.follows = "nixpkgs"; | 00:24:30 |
| kenji | In reply to @elonsroadster:matrix.org
Thanks a-kenji super helpful. Okay looking at it now, the problem is pretty deep down there in a transitive dependency. Is the right way to do this to make the dependency explicit and then explicitly set all the follows? You should be able to set implicit dependencies you got from the registry as follows I believe. But I personally always use them explicit. | 00:26:27 |
| elonsroadster | right, but i still have to be explicit all the way down with all of my flakes.
just a pain because my tree is huge
❯ nix flake metadata | wc
warning: Git tree '/home/imalison/dotfiles' is dirty
113 419 13474 | 00:27:20 |
| kenji | Yes, I believe that is correct. I think you can't point all nixpkgs that are in the tree automatically to a specific nixpkgs version, if that is what you are asking. | 00:28:29 |
| elonsroadster | it actually might not be too hard to write a function to flatten everything though. Clearly there is a function that nix flake metadata calls, and you could probably write something to automatically flatten things to the top level for you, as long as everything is going to work using the same version of everything as identified by the flake input name | 00:31:45 |
| kenji | In reply to @elonsroadster:matrix.org
it actually might not be too hard to write a function to flatten everything though. Clearly there is a function that nix flake metadata calls, and you could probably write something to automatically flatten things to the top level for you, as long as everything is going to work using the same version of everything as identified by the flake input name I don't think you can write functions in the inputs, but you could probably write some external tool that does it. | 00:37:21 |
