 | Nixpkgs Stdenv | 232 Members |
| 75 Servers |
| Nixpkgs Stdenv | 232 Members |
| 75 Servers |
| Sender | Message | Time |
|---|---|---|
| 7 Jan 2025 | ||
 emily | forcing people to specify just makes everything far more confusing :/ | 00:25:09 |
| emily | however that would be some additional lower-level work to make happen I think | 00:25:17 |
 Toma | I think some extra package-sets need to be added with null targets, no? | 00:25:45 |
| emily | 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 |
| emily | (free name bikeshed colour: mkPackage) | 00:26:44 |
| Toma | 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 |
| emily | (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 |
| emily | (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 |
| emily | I was actually thinking of it just as a less verbose name for finalAttrs, but that might work too :) | 00:28:20 |
| 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 |