| 13 Dec 2023 |
 nbp | The problem is that this is per-value, and thus we lose the recurisve attribute sets, where one define the result based on another attribute.
This could still be provided through the final resume-point, assuming that the resolver is at the end of Nixpkgs. | 15:21:13 |
 Robert Hensing (roberth) | The exact merging semantics is to be decided. It will be easier when we have a prototype that we can benchmark and play around with. | 15:36:58 |
| Robert Hensing (roberth) | Added that to the issue text as well | 15:38:14 |
| Robert Hensing (roberth) | * Added that to the issue text as well just now | 15:38:21 |
 infinisil | nbp: That actually reminds me of https://nixos.org/manual/nixpkgs/stable/#function-library-lib.attrsets.updateManyAttrsByPath | 16:05:14 |
|  9999years joined the room. | 20:23:53 |
| 9999years | should RFC 140 be a mechanism just for nixpkgs (which has fairly unique requirements, like being large enough to necessitate sharding package names) or should it also be a user-facing mechanism for creating package sets from directories?
i'd like to add a user-facing mechanism for creating package sets from directories (#270537) and infinisil hasn't been sure whether or not it should be the same mechanism as pkgs/by-name. i'd like to make a decision on this so that we can ship something, and then we can iterate and improve from there
| 20:27:16 |
| infinisil | 9999years: A big future idea with RFC 140 was to use the package directories for more than just the package definition itself. | 23:47:57 |
| infinisil | So we could have e.g. a module.nix file that specifies a NixOS module (or home-manager module, or some abstract module, ..) | 23:48:21 |
| infinisil | Or a meta.nix, which would allow querying package metadata without much evaluation | 23:48:39 |
| infinisil | Or some way to specify overrides. args.nix maybe, but that's very ad-hoc. Maybe rather something like dependencies.nix and config.nix or so | 23:49:34 |
| infinisil | And this kind of idea would be really useful to have standardised, such that people can write third-party package directories, and upstreaming to Nixpkgs will be just a matter of a cp -r. Or even better: Allow third-party repositories to have their package directories be automatically pulled into Nixpkgs | 23:50:38 |
| infinisil | And yes this does sound a lot like the Flakes output schema, but I don't think we can use that directly in its current state | 23:52:56 |
| infinisil | 9999years: But yeah, having https://github.com/NixOS/nixpkgs/pull/270537 won't prevent such a standardisation in the future. I don't think new approaches should be introduced when there's already an existing one. But in this case there isn't an existing approach, so I don't want to block that. | 23:56:37 |
| 14 Dec 2023 |
| 9999years | maybe we could merge it with callPackage and then adapt it to use packageFromDirectory in the future (and add an assert that only one is supplied)...? | 00:02:34 |
| infinisil | Not sure what you mean by merging it with callPackage | 00:14:38 |
