| 6 Jan 2025 |
 emily | https://github.com/NixOS/nixpkgs/issues/371465 | 19:54:30 |
 Randy Eckenrode | I saw the issue. Was this not a problem no one noticed before because it was just the CoreFoundation headers and stubs? | 19:55:11 |
| Randy Eckenrode | * | 19:55:41 |
| Randy Eckenrode | The SDK pulls in a toolchain because it symlinks some stuff in $DEVELOPER_DIR/usr/bin because Chromium. | 19:57:06 |
| Randy Eckenrode | Isn’t the easy fix to drop extraBuildInputs on Darwin? | 19:57:40 |
| Randy Eckenrode | * Isn’t the easy fix to drop extraBuildInputs from stdenvNoCC on Darwin? | 19:57:56 |
| emily | yes | 19:58:31 |
| emily | I was trying to figure out how to do this | 19:58:34 |
| emily | https://github.com/NixOS/nixpkgs/pull/371539 it evals, trying a build on x86_64-darwin, looks like there's some unrelated darwin.libffi fallout on AArch64 | 20:00:53 |
| 7 Jan 2025 |
 Toma | Would appreciate some feedback
https://github.com/NixOS/nixpkgs/pull/371613
this is partially based on some earlier conversations which I don't have the time to find right now, but I think amjoseph was part of it | 00:19:15 |
| emily | oh I will have a lot of opinions about this | 00:20:49 |
| emily | fwiw there is also https://github.com/NixOS/nixpkgs/pull/296769 | 00:21:05 |
| emily | my #1 request: do the depsInPath/deps thing, but make them attribute sets, and have overrides work by the name | 00:21:59 |
| emily | e.g., deps = { inherit (pkgsOnHost) zlib ffmpeg; } but deps = { inherit (pkgsOnHost) zlib; ffmpeg = pkgsOnHost.ffmpeg_7; boost = pkgsOnHost.boost179; } | 00:22:35 |
| emily | this (a) gets rid of with footguns and (b) gets rid of the "put version pins in all-packages.nix for sane overriding interface, or in the package for locality" dilemma | 00:22:59 |
| emily | I'd also suggest not bundling the package sets under finalAttrs. just do something like e.g. mkDerivation2 ({ self, pkgsOnHost, ... }: …) | 00:23:42 |
| emily | I really want the targetPlatform = null stuff from https://github.com/NixOS/nixpkgs/issues/227327 to make specifying explicit cross package sets saner. feel like # do we care that it's pkgsBuildHost? is hinting at that confusion :) | 00:24:47 |
| emily | for 99.9% of packages, pkgsBuildHost = pkgsBuildBuild = pkgsBuildTarget | 00:24:59 |
| 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 |
