| 24 Oct 2025 |
 emily | though I deleted most of that stuff | 02:28:38 |
 samasaur | i'm really baffled by why CFNetwork and Network behave differently | 02:29:01 |
| samasaur | they appear to be treated identically by qt, and we don't seem to do any patching for either of those explicitly | 02:29:51 |
| samasaur | so as I understand it either both should be picked up from the SDK or neither should be | 02:30:11 |
 Randy Eckenrode | That would remove the SDK. You’d have to add it back. | 02:31:05 |
| emily | right | 02:31:40 |
| emily | seems best to just fix the cross stdenv. if only I knew why it was broken | 02:31:47 |
| Randy Eckenrode | I think less specific to this example is coming up with a solution to the general problem of conditional arguments. The solution given in the by-name RFC was to add your package to all-packages.nix, but it seems the desire now is not to have packages there? | 02:32:19 |
| Randy Eckenrode | That’s one example. It’s potentially anything that has a recursive dependency that the bootstrap had to break up. | 02:33:03 |
| Randy Eckenrode | Like in the old source-based SDK how xnu depended on python3 but relied on the bootstrap to override it with python3Minimal to break the infinite recursion. | 02:34:15 |
| emily | that shouldn't be an issue for cross though | 02:38:40 |
| emily | since cross already has a bootstrapped toolchain | 02:38:44 |
| emily | right? | 02:38:51 |
| emily | it's only buildInputs, not nativeBuildInputs, that can cause problems | 02:39:03 |
| Randy Eckenrode | IIRC, it was an issue with adding cross support to the old SDK. | 02:39:20 |
| emily | well, this is details of the exact arrangement of bootstrap leaking into individual packages, which is not ideal since the former can change and it's why all the overlays/overrides are in pkgs/stdenv to begin with | 02:39:56 |
| emily | https://github.com/NixOS/nixpkgs/pull/444420 addressed the most common case of overrides by far | 02:40:27 |
| emily | the nominal convention would be to give atf a withStdenvPackage if one really wants to provide its override as a public API but that would be quite ridiculous | 02:40:51 |
| Randy Eckenrode | But this is also beside the point. Any package that conditionally set a parameter had to do it in the attrset passed to callPackage because you can’t do it in the function arguments definition (because callPackage will see them and ignore it IIRC). | 02:41:17 |
| emily | a much richer override interface that has explicit delineation of public API and supports real interface stability and fancier defaults is something I am thinking about | 02:41:20 |
| Randy Eckenrode | * But this is all beside the point. Any package that conditionally set a parameter had to do it in the attrset passed to callPackage because you can’t do it in the function arguments definition (because callPackage will see them and ignore it IIRC). | 02:41:29 |
| emily | but this specific case is really marginal | 02:41:36 |
| Randy Eckenrode | Version-specific arguments make the Haskell package set extremely annoying to use if you don’t want an LTS release. | 02:44:26 |
| emily | the Haskell package set is specifically designed around pinning a specific Stackage LTS | 02:45:09 |
| emily | though they are working on maintaining a parallel Nightly package set AIUI | 02:45:16 |
| Randy Eckenrode | Yeah. I hate it for applications. | 02:45:30 |
| Randy Eckenrode | I want to use the latest hledger because it has some QoL improvements, but I can’t because that’s not what’s in the Stackage LTS. | 02:46:22 |
| emily | you can have specific additional versions of given packages, AIUI | 02:46:41 |
| emily | it just needs adding in the config file | 02:46:45 |
| Randy Eckenrode | I have something hacky that works for a somewhat newer version, but I don’t think I can govnewer than that. | 02:46:49 |
