Nixpkgs Stdenv | 221 Members | |
| 72 Servers |
| Sender | Message | Time |
|---|---|---|
| 7 Jan 2025 | ||
right (unless we can get away with just hacks to pass them stdenvs with the target stubbed out) and probably a lot of assumptions need correcting for that. | 00:26:26 | |
(free name bikeshed colour: mkPackage) | 00:26:44 | |
now that I think about it, self, (which I think means finalAttrs.finalPackage) contains everything that finalAttrs does so in theory we could just skip giving access to finalAttrs, but it might make it more confusing | 00:27:21 | |
(though actually I'd be somewhat tempted to make it a new by-name interface – like package2.nix is just the { self, pkgsOnHost, ... }: … part and the mkPackage is implicit) | 00:27:43 | |
(that way you eliminate the extra layer of { lib, mkDerivation2 }: and never make the terrible mistake of getting a spliced package from that level) | 00:28:00 | |
I was actually thinking of it just as a less verbose name for finalAttrs, but that might work too :) | 00:28:20 | |
| yeah maybe, though we always have to make sure non nixpkgs users can healthily consume single file package definitions | 00:29:08 | |
(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 | |
(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 | |
| * yeah maybe, though we always have to make sure non-nixpkgs consumers of mkDerivation2 can healthily use it | 00:30:03 | |
callPackage2 :p | 00:30:09 | |
| heh | 00:30:14 | |
I mean mkDerivation2 is basically doing the job of callPackage | 00:30:36 | |
| anyways I really have to go to sleep now, I messed up my schedule implementing this, bye!! | 00:30:40 | |
| since it is also handling overrides | 00:30:40 | |
| (*in the form I want it to be at least) | 00:30:45 | |
| sleep well :) | 00:30:51 | |
| sorry for the deluge of immediate feedback I've been thinking about this for too long | 00:31:02 | |
| 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 | |
| * 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 | |
| * 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 | ||
| 09:16:03 | ||
| 11 Jan 2025 | ||
| 21:21:04 | ||
| 13 Jan 2025 | ||
| Updated my POC https://github.com/NixOS/nixpkgs/pull/371613 | 01:15:33 | |
| 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 | |
| * 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 | |
fwiw finalAttrs.finalPackage.doCheck ≠ finalAttrs.doCheck | 01:20:23 | |
finalPackage has post-processing | 01:20:37 | |
| and ideally splicing would be totally irrelevant to a new construct :) | 01:20:58 | |
| it's only there as a hack for backwards compatibility | 01:21:01 | |