| 6 Dec 2023 |
 infinisil | Making some progress with RFC 140: https://github.com/NixOS/nixpkgs/pull/272395 (still a draft, not ready for review, but the description gives the story) | 02:38:00 |
 Philip Taron (UTC-8) | infinisil: I love pkgs/by-name and I write Rust at work. I'd be glad to be code reviewer when you' | 05:01:31 |
| Philip Taron (UTC-8) | * infinisil: I love pkgs/by-name and I write Rust at work. I'd be glad to be code reviewer when you're ready. | 05:01:35 |
| infinisil | Philip Taron: Oh awesome, that would be very welcome, thanks! I'll mark it as ready to review when done :) | 05:12:01 |
| 12 Dec 2023 |
| infinisil | Nothing concrete, but just wanted to point out this issue: https://github.com/NixOS/nixpkgs/issues/273534 | 17:43:46 |
 tomberek | In reply to @infinisil:matrix.org
Nothing concrete, but just wanted to point out this issue: https://github.com/NixOS/nixpkgs/issues/273534 We keep seeing this. And the current flake usage makes this worse. I opened: https://github.com/nixpkgs-architecture/issues/issues/25 , still needs work and discussion. | 17:49:48 |
 Robert Hensing (roberth) | Braindump of an actually feasible module-like packaging method for Nixpkgs, if you're interested. https://github.com/NixOS/nixpkgs/issues/273815 | 19:46:52 |
 bew | Found an unfinished sentence starting with "This should not include redundant (and slow)" | 22:29:32 |
| Robert Hensing (roberth) | Thanks. Edited. That was going to be about mkDerivation package attr stuff and multi-outputs, but the latter got its own section. | 23:06:06 |
| 13 Dec 2023 |
 nbp | “Bring all packaging layers into a single fixpoint” This is already the case, unless you are thinking about the bootstrap of the compilers, which is something I wanted to at one point. | 10:09:14 |
| nbp | Nixpkgs is already a fix-point of merged functions (final: prev: { … }) | 10:13:53 |
| nbp | Robert Hensing (roberth): I think we disagree on what qualifies as a module system, and your definition already encapsulate Nixpkgs as a module system, as I understand it. | 10:23:11 |
| nbp | The core of the problem of override is that we have to peel the layers of executed functions in order to patch what was inside.
This can be avoided by not calling mkDerivation but making it an attribute in the attribute set which is used to define a package, and then add an extra phase in charge of evaluating packages by calling the attribute which holds the mkDerivation with the attribute set of the package. I was not able to see this extra phase in your brain dump.
| 10:26:48 |
| 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 |
