| 17 Mar 2024 |
K900 | Probably about as well as it can without flakes having to know about the details of the channel tarball format | 14:17:37 |
infinisil | Maybe if channels were more first-class in Flakes, we wouldn't even need the channel branches | 14:17:59 |
Robert Hensing (roberth) | That's all besides the point. If you don't add the CNF data to a Nixpkgs package, no branch will have it | 14:18:43 |
Robert Hensing (roberth) | except maybe the special ones | 14:18:50 |
infinisil | Oh you want branches that haven't been built by Hydra to also have some database | 14:19:19 |
infinisil | So like a fallback database | 14:19:22 |
Robert Hensing (roberth) | Yes, I want to enable CNF in my config, and switch to someone's PR branch to test things out | 14:19:48 |
Robert Hensing (roberth) | Or maybe I'm in a situation where I need something custom that's not upstreamable yet or whatever | 14:20:09 |
Robert Hensing (roberth) | That should not force me to disable CNF | 14:20:17 |
Robert Hensing (roberth) | Like a fallback database, yes, but the fallback aspect is mostly irrelevant | 14:20:41 |
infinisil | So I guess somebody could like set programsSqlite = pkgs.fetchurl "https://my-url.com/programs.sqlite" | 14:22:07 |
Robert Hensing (roberth) | Well, if they care to set that up, but otherwise they have a db that works 99.5% of the time, which is great | 14:23:40 |
infinisil | Very related: https://github.com/NixOS/nixpkgs/pull/252057 | 14:23:41 |
Robert Hensing (roberth) | Yeah, might as well record which channel version it's based on - keep another data package in sync | 14:24:37 |
Robert Hensing (roberth) | (not exactly the same thing, but related indeed) | 14:26:33 |
infinisil | Alternatively, consider a more powerful idea of having a meta-Nixpkgs repository, which contains all historical versions of Nixpkgs that were built by Hydra, with all their metadata. This could include things like whether builds succeeded, which versions are available in which channel, what is the latest release, etc. | 14:27:17 |
infinisil | Robert Hensing (roberth): This reminds me of the release notes problem you're having with Nix, where some release notes are only available in release branches, never getting to master from where the manual is rendered | 14:28:52 |
infinisil | I can see such meta repositories also solving that problem | 14:30:07 |
infinisil | Oh and it should be purely additive, no data should ever be removed from such repos | 14:30:21 |
infinisil | Which means they don't even need to be repos really, though that might be easiest | 14:30:34 |
infinisil | And at that point we're back at maybe it should just be a channel! | 14:30:48 |
| willbush left the room. | 14:48:32 |
| willbush joined the room. | 14:48:50 |
| willbush left the room. | 14:49:53 |
| willbush joined the room. | 14:50:26 |
tomberek | Sounds very much like the catalogs we had been working on. Doing them all is likely too much, but we can make a 1-1 relationship as a starting point, before doing all of history at once. | 14:52:51 |
tomberek | Do you mean something close to: https://github.com/on-nix/pkgs ? | 14:54:11 |
willbush | infinisil: is there a way to manually run by-name tests? for example, I was trying cargo run -- --base ./tests/empty-base ./tests/aliases | 14:57:20 |
infinisil | willbush: Ahh there isn't, I usually do cargo test to run them all | 14:58:55 |
infinisil | That's actually something I'd love to have improved: Currently when I update error messages, I manually update the error messages in the tests. I'd rather just be able to regenerate them | 14:59:34 |