| 23 Jun 2023 |
 emily | not impossible, but kind of gross. | 12:08:04 |
 CRTified | You're writing a kind of meta-flake then? 😄 | 12:08:27 |
| emily | it's in the context of nixos's manual generator which currently has a weird way of mapping option definition locations to source URLs | 12:09:08 |
| emily | was trying to come up with something better and wondering how much could be automated from flake inputs | 12:09:22 |
|  bl1nk changed their profile picture. | 21:49:21 |
| 25 Jun 2023 |
 @arianvp:matrix.org | What is the rationale for hydraJobs being <package>.<system> as opposed to<system>.<package> ? | 08:49:16 |
 Sandro 🐧 | Probably because the supported platforms are depending on the package | 08:59:48 |
 nf | supported packages also depend on the platform ;) | 13:27:51 |
|  @realbeing2453tyhr:matrix.org joined the room. | 20:12:31 |
| emily | my guess: because it's how hydra jobs have always been named on the site in the pre-flakes era? | 21:49:09 |
| emily | plays nicer with sorting, i guess | 21:49:27 |
| @realbeing2453tyhr:matrix.org changed their display name from realbeing2453tyhr to 2453tyhr. | 23:08:22 |
| @realbeing2453tyhr:matrix.org set a profile picture. | 23:10:54 |
| 26 Jun 2023 |
|  beect joined the room. | 03:58:44 |
 Jhu | So, if I use Flakes for anything more complex with 3rd party flake dependencies, it seems that the dependencies get totally out of hand. What is the correct way of managing the chain of recursive sub-dependencies of flakes so that I would not end up with 10 different hard locked revisions of nixpkgs to use the top level Flake?
Or is the only way to crawl through all those dependent flakes and do manual overrides? Surely there has to be a better way? | 08:37:04 |
| emily | nix flake metadata can help you track them down | 08:45:31 |
| emily | but that's pretty much how it goes. flakes will often make their inputs follow their own nixpkgs, so you can just override the top-level nixpkgs to get most of them | 08:45:46 |
| emily | also, it's not necessarily that much of a problem to have different nixpkgs versions if you are consuming flakes through an overlay or nixos module, since in that case they will use your "main" nixpkgs anyway | 08:46:15 |
| CRTified | In reply to @emilazy:matrix.org
also, it's not necessarily that much of a problem to have different nixpkgs versions if you are consuming flakes through an overlay or nixos module, since in that case they will use your "main" nixpkgs anyway That might be important to be stressed a bit more. You made me just aware of that, and the consequence (for me) would be that providing overlays is better than providing packages, at least if there is no CI updating the flake.lock | 09:06:07 |
| emily | on the other hand, providing packages is important too, for CLI usability :/ | 09:06:41 |
| emily | and when packages.* are based on overlays it results in more nixpkgs imports for people like me who try to keep to 0 overlays... so really you have to provide both. it's an awkward situation | 09:07:07 |
| CRTified | Yeah. I'd probably go with "put the mkDerivation call In a let binding, reuse that in an overlay and package" | 09:07:30 |
| emily | the flakes docs do say "btw don't care about nixpkgs duplication because everyone uses overlays" but uh, i would not say that that statement accurately describes existing practice | 09:07:47 |
| emily | (and in fact I think it was written before many were using flakes at all so it was really a prescription written as a descriptive statement...) | 09:08:03 |
| emily | this is certainly one of the awkward parts of the existing flakes design, imo | 09:08:21 |
| CRTified | For one-time use, having an old nixpkgs dependency is likely fine, while using it in a config makes overlays more useful | 09:08:26 |
| CRTified | In reply to @emilazy:matrix.org
the flakes docs do say "btw don't care about nixpkgs duplication because everyone uses overlays" but uh, i would not say that that statement accurately describes existing practice Yeah, I think I'm using modules and packages more than overlays, at least from flake inputs | 09:09:34 |
| * emily 's config uses 0 overlays in favour of packages outputs and tries to only evaluate nixpkgs once, but it's a bit of a pain sometimes. and of course sometimes you do actually need to override a dependency | 09:10:41 |
| emily | but i did, even in the pre-flakes days, sort of dislike using an overlay just to add leaf packages | 09:10:59 |
| emily | feels less structured | 09:11:18 |
