 | Nixpkgs Stdenv | 252 Members |
| 78 Servers |
| Nixpkgs Stdenv | 252 Members |
| 78 Servers |
| Sender | Message | Time |
|---|---|---|
| 7 Jan 2025 | ||
 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 |