| 7 Jan 2025 |
 Toma | heh | 00:30:14 |
 emily | I mean mkDerivation2 is basically doing the job of callPackage | 00:30:36 |
| Toma | anyways I really have to go to sleep now, I messed up my schedule implementing this, bye!! | 00:30:40 |
| emily | since it is also handling overrides | 00:30:40 |
| emily | (*in the form I want it to be at least) | 00:30:45 |
| emily | sleep well :) | 00:30:51 |
| emily | sorry for the deluge of immediate feedback I've been thinking about this for too long | 00:31:02 |
| Toma | Updated the POC to include some deps/depsInPath examples.
It is not part of mkDerivation2, but implemented per-package, currently.
Also, since we don't use callPackage path {}, but import path pkgs the should be no splicing involved.
(though we might get a spliced package through an override. what to do about that....)
Also removed the ability to override __pkgs so now we don't have to use finalAttrs.__pkgs if we know the package's package set.
| 08:54:16 |
| Toma | * Updated the POC to include some deps/depsInPath examples.
It is not part of mkDerivation2, but implemented per-package, currently.
Also, since we don't use callPackage path {}, but import path pkgs there should be no splicing involved.
(though we might get a spliced package through an override. what to do about that....)
Also removed the ability to override __pkgs so now we don't have to use finalAttrs.__pkgs if we know the package's package set.
| 09:12:35 |
| Toma | * Updated the POC to include some deps/depsInPath examples.
It is not part of mkDerivation2, but implemented per-package, currently.
Also, since we don't use `callPackage path {}`, but `import path pkgs` there should be no splicing involved.
(though we might get a spliced package through an override. what to do about that....)
Also removed the ability to override __pkgs so now we don't have to use finalAttrs.__pkgs if we know the package's package set.
| 09:13:19 |
| 10 Jan 2025 |
|  xanderio joined the room. | 09:16:03 |
| 11 Jan 2025 |
|  pandapip1 joined the room. | 21:21:04 |
| 13 Jan 2025 |
| Toma | Updated my POC
https://github.com/NixOS/nixpkgs/pull/371613 | 01:15:33 |
| Toma | it is defined in terms of layers (the list of layers is currently static, but should be pretty straightforward to make extendible to be used by things like buildRustPackage.
and also finalAttrs is now actually the same as finalPackage
the cross stuff is not better than a few days ago, but I have at least read the splicing and bootstrapping implementations, which should help me | 01:16:08 |
| Toma | * it is defined in terms of layers (the list of layers is currently static, but should be pretty straightforward to make extendible to be used by things like buildRustPackage.)
and also finalAttrs is now actually the same as finalPackage
the cross stuff is not better than a few days ago, but I have at least read the splicing and bootstrapping implementations, which should help me | 01:16:28 |
| emily | fwiw finalAttrs.finalPackage.doCheck ≠ finalAttrs.doCheck | 01:20:23 |
| emily | finalPackage has post-processing | 01:20:37 |
| emily | and ideally splicing would be totally irrelevant to a new construct :) | 01:20:58 |
| emily | it's only there as a hack for backwards compatibility | 01:21:01 |
| Toma | In reply to @emilazy:matrix.org
fwiw finalAttrs.finalPackage.doCheck ≠ finalAttrs.doCheck well, it is the same now, since finalAttrs = finalPackage
The fix point IS the package | 01:30:49 |
| emily | how do you handle doCheck then? | 01:31:02 |
| Toma | It just "extends" the user given value.
(I used userValue.doCheck or ...canExecute..., but I could have done userValue.doCheck && ...canExecute...)
Just like you would extend nativeBuildInputs with by appending some hooks in the case of buildRustPackage
So even though the user wrote some value, the final value might have changed slightly.
There is currently a way to access all other layers (e.g. before doCheck was extended), but this introduces correctness problems. | 01:35:18 |
| Toma | * It just "extends" the user given value.
(I used userValue.doCheck or ...canExecute..., but I could have done userValue.doCheck && ...canExecute...)
Just like you would extend nativeBuildInputs by appending some hooks in the case of buildRustPackage or buildNpmPackage
So even though the user wrote some value, the final value might have changed slightly.
There is currently a way to access all other layers (e.g. before doCheck was extended), but this introduces correctness problems. | 01:36:06 |
| Toma | But do take a look at the implementation.
Also the lowest layer of transformation relies on the entirely undocumented builtins.derivationStrict | 01:37:55 |
| emily | right | 02:29:33 |
| emily | I'll try and take a look at some point (quite busy) | 02:29:39 |
| 14 Jan 2025 |
 ネコ | can someone look at #358042? it's a trivial fix and it's been preventing me from building any flakes for several months. | 17:08:45 |
| 15 Jan 2025 |
|  SomeoneSerge (back on matrix) changed their display name from SomeoneSerge (utc+3) to SomeoneSerge. | 19:02:58 |
| 16 Jan 2025 |
|  FliegendeWurst joined the room. | 09:37:40 |
| 17 Jan 2025 |
|  chintuchamar joined the room. | 04:40:34 |
