| 6 Jul 2021 |
 David Arnold (blaggacao) | In reply to @tomberek:matrix.org
David Arnold: perhaps I’m not understanding your goal. If the resulting lock file is what you want, then okay, but something doesn’t smell right. I'm really just playing around, but yeah my impetus here was to craft a genuinely useful lock file that only holds (transient) dependencies that you actually depend on. I think the lock file could be pretty nice basis for a SBOM, eventually: it has all the info and useful metadata to reconstruct a DAG. This strategy, of course, cannot be right as long as fetch* are allowed outside of inputs, since they would not enter such SBOM. | 23:11:42 |
| David Arnold (blaggacao) | * I'm really just playing around, but yeah my impetus here was to craft a genuinely useful lock file that only holds (transient) dependencies that you actually depend on. I think the lock file could be pretty nice basis for a SBOM, eventually: it has all the info and useful metadata to reconstruct a DAG. This strategy, of course, cannot be right as long as `fetch*` are allowed outside of `inputs`, since they would not enter such SBOMs that are based of the lock file. | 23:12:22 |
 mvnetbiz | Can't you just get a DAG from nix-store --graph | 23:18:08 |
| mvnetbiz | Just what flakes you include doesn't give you a very accurate view on anything you build, especially if you have something like nixpkgs which could be any number of tens of thousands of packages | 23:20:20 |
| David Arnold (blaggacao) | In reply to @mvtva:matrix.org
Can't you just get a DAG from nix-store --graph Yeah that's probably the better idea. 😃 Maybe there is a slight advantage to use a checked in file. | 23:29:23 |
| David Arnold (blaggacao) | In reply to @mvtva:matrix.org
Just what flakes you include doesn't give you a very accurate view on anything you build, especially if you have something like nixpkgs which could be any number of tens of thousands of packages That is currently true, but if the vision is to be held up, I guess any fetching outside of inputs could be forbidden. Then, we'd at least not have to deal with missing items. | 23:30:39 |
| David Arnold (blaggacao) | * That is currently true, but if the vision is to be held up, I understand any fetching outside of inputs could be forbidden. Then, we'd at least not have to deal with missing items. | 23:31:07 |
| David Arnold (blaggacao) | ... that means all of nixpkgs to become a collection of flakes, first, of course. | 23:32:21 |
| David Arnold (blaggacao) | I also set up divnix/blank to let input follows "speak" (more) meaningfully. | 23:34:25 |
| David Arnold (blaggacao) | I now can convey that I don't care about an upstream flake's input because I never hit that codepath. | 23:35:01 |
| mvnetbiz | How can everything be in inputs? You can't have a fetchFromGitHub in flake inputs | 23:35:10 |
| David Arnold (blaggacao) | In reply to @mvtva:matrix.org
How can everything be in inputs? You can't have a fetchFromGitHub in flake inputs I think the goal is everything that goes into the flake from the outside has to be an "input" (after all that's what the name suggests). | 23:36:11 |
| mvnetbiz | Do you just want a list of what .nix sources are strictly needed to evaluate your flake outputs? | 23:43:00 |
| mvnetbiz | For your example of blanking nixos-generators, I guess your point is that if you are only using the nixos modules from that flake, then you don't need the command line tool or whatever depends on nixpkgs? Since the only use for a nixos module is a nixos system, I would think it would be more apt to override nixos-generators.follows with your own version of nixpkgs instead of blanking it, since you are depending on a nixpkgs somewhere anyways. | 23:45:24 |
| mvnetbiz | I think your idea of it potentially being useful to just having a checked in file with information that doesn't need to be highly processed (by nix) to read is valid though. | 23:48:50 |
| 7 Jul 2021 |
| David Arnold (blaggacao) | Yeah, 100%! I like the blanking since it also tells the (attentive) reader a story. It is somewhat obvious that we don't car about its nixpkgs dependency although, we ourselves might depend on it. | 00:49:05 |
| David Arnold (blaggacao) | In the Unofficial Flake Roadmap that I formulated some time ago, I had the idea of input groups that are mapped to outputs, so that the usage of any specific output can have a better view on the direct inputs required. | 00:50:02 |
| David Arnold (blaggacao) | * In the Unofficial Flake Roadmap that I compiled a couple of days ago, I had the idea of input groups that are mapped to outputs, so that the usage of any specific output can have a better view on the direct inputs required. | 00:50:26 |
| David Arnold (blaggacao) | * Yeah, 100%! I like the blanking since it also tells the (attentive) reader a story. It is somewhat obvious that we don't care about its nixpkgs dependency although, we ourselves might depend on it. | 00:53:46 |
| mvnetbiz | You can have multiple flakes in 1 git repo and reference lower ones from a top level flake.nix, I think I saw an example of this already somewhere | 01:15:55 |
| mvnetbiz | That might already suit that use case and not require more complicated flake implementation | 01:16:35 |
| David Arnold (blaggacao) | Yeah, this is a good idea! I tried to do that myself, as well. It feels a bit heavy handed, if it's just for a devShell or a checks implementation of the top level flake that depends on some extra depeendencies. But maybe the vision for flakes is to be super slim. | 13:38:14 |
| David Arnold (blaggacao) | ... if that's the case though, we could as well argue the outputs should be limited to a single output. | 13:38:49 |
| David Arnold (blaggacao) | * Yeah, this is a good idea! I tried to do that myself, as well. It feels a bit heavy handed, if it's just for a `devShell` or a `checks` implementation of the top level flake that depends on some extra dependencies. But maybe the vision for flakes is to be super slim. | 13:39:11 |
| David Arnold (blaggacao) | * ... if that's the case though, we could as well argue `outputs` should be limited to a single output. | 13:39:30 |
|  multivariante set a profile picture. | 21:22:56 |
| David Arnold (blaggacao) | https://github.com/NixOS/nix/pull/4641 is making quite some good progress! If CitadelCore where in this room, my expression of thankfulness could reach them directly. | 22:17:29 |
| David Arnold (blaggacao) | niksnut: maybe you can have a look at it? It's quite an annoying bug that precludes from effectively aligning the starts when trying to use the follows notation. I think a lot of people just move on and are secluded from harnessing the true powers of follows, so I find it extremely refreshing that CitadelCore has taken on the task. | 22:19:20 |
| David Arnold (blaggacao) | * niksnut: maybe you can have a look at it? It's quite an annoying bug that precludes from effectively aligning the starts (=inputs) when trying to use the follows notation. I think a lot of people just move on and are secluded from harnessing the true powers of follows, so I find it extremely refreshing that CitadelCore has taken on the task. | 22:19:35 |
| 9 Jul 2021 |
| multivariante left the room. | 00:21:40 |
