 | Nixpkgs Stdenv | 225 Members |
| 74 Servers |
| Nixpkgs Stdenv | 225 Members |
| 74 Servers |
| Sender | Message | Time |
|---|---|---|
| 7 Jan 2025 | ||
 Toma | yeah maybe, though we always have to make sure non nixpkgs users can healthily consume single file package definitions | 00:29:08 |
 emily | (I was really happy when I thought of this because it's an excuse to use inherit rather than with with explicit package sets that also happens to solve a major overrides pain point) | 00:29:23 |
| emily | (it happens quite a lot that you pick some specific package variant in your dependencies header and that causes override issues, being able to define the interface locally is really nice since all-packages.nix action at a distance sucks and gets in the way of by-name) | 00:29:56 |
| Toma | * yeah maybe, though we always have to make sure non-nixpkgs consumers of mkDerivation2 can healthily use it | 00:30:03 |
| emily | callPackage2 :p | 00:30:09 |
| 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 Also, since we don't use (though we might get a spliced package through an override. what to do about that....) Also removed the ability to override | 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 finalPackagethe 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 finalPackagethe 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.orgwell, 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 |