| 23 Jun 2023 |
 CRTified | https://github.com/kanwren/nix-parsec That might be helpful 🤔 | 12:03:19 |
| CRTified | Especially https://github.com/kanwren/nix-parsec/pull/6 | 12:03:43 |
 emily | i imagine it'll be miserably slow :) | 12:04:07 |
| emily | but it might be fun anyway | 12:04:13 |
| emily | i need to sleep, hopefully when i wake up i'll have shaken this dread curse that makes me think trying to reimplement nix's flake.nix parsing logic to poke at an unknown inputs.self is a good idea | 12:05:01 |
 twitchy0 | In reply to @emilazy:matrix.org
you shouldn't give me ideas like this, this is dangerous I think it's acceptable. Self is considered a flake input, and nix will put your working code in the nix store so you do still have purity in inputs.
I can maybe see danger with instability, but it seems like fair game to me to use the flake.lock | 12:06:01 |
| twitchy0 | I should say "flake is considered a flake input" only from understanding, dunno about officially | 12:07:29 |
| emily | yeah, in this case self would be some unknown third party's flake though | 12:07:43 |
| twitchy0 | You certainly don't declare it at such, so it's implicit | 12:07:49 |
| emily | and there's no guarantee there's a lock, only flake.nix | 12:07:51 |
| emily | so it would be "interesting". | 12:07:54 |
| twitchy0 | Ah | 12:07:57 |
| 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 |
