| 9 Feb 2025 |
|  preston ⚡️ joined the room. | 07:41:18 |
| preston ⚡️ | hi, i was wondering if it was:
- possible to use multiple URLs for a single flake input as a fallback, and
- if it is not currently possible, if it would get merged if there was a PR for it, and
- if it would not get merged, why it is a bad idea
| 10:39:30 |
|  sinan changed their profile picture. | 14:43:19 |
| sinan changed their display name from Sinan (comfy) to sinan. | 14:43:29 |
| sinan changed their profile picture. | 14:47:57 |
 Robert Hensing (roberth) | I like the idea. I think an important next question is whether we want to use an equivalence of basically whole fetchTree calls (including the type) or just the interchangeability of git remotes, or both.
The latter, multiple git remotes, seems like something that could be readily implemented, and without harming a broader fetchTree-level solution. It might become technically redundant, but then it would still provide a nice syntax that's easy to desugar (and if it's not, that means we had good reason to support both). | 15:09:04 |
| sinan changed their profile picture. | 15:41:40 |
 jade_ | https://git.lix.systems/lix-project/lix/issues/444 semi related.
i can't really say what the signal is from lix on such a feature request other than "I'm not porting it myself and there's practically not a single active developer who wants to touch flakes because they're a pit of despair". so absent someone caring about this feature enough to add it, it's going to become a lix-cppnix divergence.
Currently there is indeed probably no way to implement this in nix language today because I'm expecting the error thrown by failed fetchTree calls to be fatal. However this can be implemented today via import from derivation of pkgs.fetchurl which i think has mirror fallbacks, right?
| 18:22:58 |
| jade_ | btw for this kind of thing where it will become an implementation divergence in exposed api, i think it would be beneficial if something like https://www.chromium.org/blink/launching-features/ were implemented such that we don't implement things like builtins.convertHash without feedback from other implementations (who, in the case of lix are never going to implement convertHash because its api design is a compatibility hazard if new hash types are introduced without a mechanism like builtins.features existing https://git.lix.systems/lix-project/lix/issues/607) | 18:30:01 |
| 10 Feb 2025 |
| preston ⚡️ | I do care enough about this feature to add it. I'll probably go with the "multiple git remotes" solution first because it seems relatively simple (you don't have to deal with different source types, and also this would be my first contribution to Nix) and try for a fetchTree solution afterwards | 02:12:46 |
 ElvishJerricco | I think the way nix 2.26 is packaged in nixpkgs probably needs some changes. As far as I can tell, there's no way to override it e.g. to add a patch. I think this is a pretty ordinary use case. | 08:11:50 |
|  @twig6943:matrix.org changed their profile picture. | 14:36:05 |
|  @550mg:matrix.org left the room. | 19:59:11 |
| 11 Feb 2025 |
|  -chi left the room. | 20:21:59 |
| 12 Feb 2025 |
|  LinearArray changed their profile picture. | 22:48:30 |
| 13 Feb 2025 |
|  connor (burnt/out) (UTC-8) changed their display name from connor (he/him) (UTC-7) to connor (he/him) (UTC-8). | 06:59:10 |
|  Alice joined the room. | 10:37:22 |
 Sandro 🐧 | I just wanted to poke about https://github.com/NixOS/nix/pull/6464 and https://github.com/NixOS/nix/issues/10202
Since thufschmitt stopped working on things, maybe someone else could pick it up? | 13:29:20 |
| 14 Feb 2025 |
| Robert Hensing (roberth) | I've opened https://github.com/NixOS/nix/issues/12472 | 00:14:43 |
 John Ericson | Robert Hensing (roberth) I think we would want to expose the individual library packages in nixpkgs? | 00:56:47 |
| John Ericson | at least with the versioned nix attrs, if we think the library structure is too unsable | 00:57:01 |
| John Ericson | e.g. I am updating nix-eval-jobs, and I would like it to only depend on the libraries it actually needs (which, to be fair, is most of them) | 00:57:48 |
| John Ericson | Robert Hensing (roberth): I also got a crazy thing where buildInputs = ... was seemingly ignoring dev, even when I explicitly did .dev! | 01:09:08 |
|  ofalvai joined the room. | 06:30:40 |
| John Ericson | https://github.com/NixOS/nix/pull/5650 Can someone approve this? It is basically entirely cherry-picks, so it just needs a quick glance | 06:33:42 |
| John Ericson | It is a foundation for old-client + new-daemon testing | 06:33:59 |
| Robert Hensing (roberth) | that seems like an internal .drvPath usage in the CLI then. I figured this might happen, but at least we were able to keep compatibility at the expression level. So basically we'd need https://github.com/NixOS/nix/issues/6507 or multi-output symlink farming in the everything derivation | 08:44:14 |
| Robert Hensing (roberth) | We already do, but it's a package attribute containing the package set instead of a scope / package set that sits in pkgs or nixVersions or whatever. Touches on ElvishJerricco 's Monday thread. | 08:48:47 |
| Robert Hensing (roberth) | I think a package with a package set on top is a decent interface. Ultimately it's the same thing though. Just a different view on the same scope or fixpoint. | 08:50:51 |
| sinan changed their profile picture. | 12:15:49 |
