| 13 Dec 2023 |
 nbp | And if you follow all these minimal set of steps, you end-up with S.O.S. which comes with the idea that we need a better way of merging values together which does not involve repeating tons of // operators, just to override something within an attribute set. | 10:29:13 |
 Robert Hensing (roberth) | What I describe merely takes a concept from the module system and uses it on its own. I don't think I've defined anything. | 12:02:09 |
| Robert Hensing (roberth) | My proposal is smaller in scope, keeping mkDerivation-like calls in top-level and such. It only tries to solve problems within a single package. | 12:04:58 |
| Robert Hensing (roberth) | My proposal solves the problem of too many layers of abstraction, not the problem of override memory consumption or anything related to top-level. Nonetheless it may unify how packages are constructed, having less diverse calls in top-level etc, so it could be a stepping stone towards S.O.S. | 12:11:59 |
| nbp | Oh … I completely misunderstood the proposal :/
Which is about using the module system -like to update the content of a derivation, and not to update Nixpkgs.
Sorry, I would have to re-read based on this expectation. | 14:38:13 |
| Robert Hensing (roberth) | Don't worry. We don't normally talk about layers at the individual package level, so I can see why you associated it that way.
(Also the proposal is to remove the ad hoc and excessive layering, so that word is kind of on the way out I guess - just useful for describing the current situation and the transition) | 15:09:49 |
| nbp | one idea of light weight merging which is almost what S.O.S. suggested would be to have a zipWithRightMergeFun, if the right hand side is a function, then this is considered to be a merging function.
Then replacing is _: newValue, appending is old: old + "exit 0", debugging is x: __trace x x | 15:19:03 |
| 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 |
| 9999years | i.e. merging #270537 with { callPackage, ... }: as the argument, and then later doing something like
{
callPackage,
}:
| 00:18:17 |
