| 19 Nov 2024 |
|  @midirhee12:tchncs.de joined the room. | 05:45:33 |
 sterni | Why is the dependency closure a concern anyways? | 13:53:34 |
| sterni | I think I don't understand the problem yet we are trying to solve | 13:53:42 |
 emily | in the case of https://github.com/NixOS/nixpkgs/pull/351768 it meant >100 more builds to test stdenv changes just because of doing the right thing to handle cross | 13:55:26 |
| emily | the hack works, but it seems basically suboptimal that switching from canExecute to the more general and capable emulator stuff brings in a bunch of stuff, especially in weird platform/cross scenarios | 13:56:28 |
| emily | I mean I thought the original C program was fine | 13:56:38 |
| emily | it just doesn't seem that sensible to be pulling in a bunch of deps for a manpage build for a core stdenv function | 13:57:04 |
| emily | In reply to @emilazy:matrix.org
the hack works, but it seems basically suboptimal that switching from canExecute to the more general and capable emulator stuff brings in a bunch of stuff, especially in weird platform/cross scenarios (well specifically cross scenarios are fine because they'd be picking another emulator I guess…) | 13:57:14 |
| emily | I don't necessarily think execline should have to be held to the standard of having a reasonable closure although it is a sufficiently simple package that it doesn't seem overly burdensome | 13:57:47 |
| emily | but like if it suddenly started depending on ShellCheck or something that would be quite awful for the return value of the nop case of a core lib function | 13:58:10 |
 Randy Eckenrode | If we do switch to emulators for things, that would open up using Rosetta 2 for aarch64- to x86_64-darwin cross. (I have started and stopped adding it several times, but it always seems pointless if it can’t be used to run tests.) | 14:06:48 |
| emily | tests are harder I think | 14:07:47 |
| emily | but it's used for some things in the tree | 14:07:51 |
| emily | e.g. completions | 14:08:14 |
| emily | and gobject-introspection nonsense | 14:08:27 |
| sterni | emily: but we always pull in a bunch of stuff for cross, I don't understand the concern?! | 14:18:29 |
| sterni | you always need to bootstrap the full native stdenv for cross tools | 14:19:09 |
| emily | sorry, I misspoke; I think the problem is more non-cross. if you change something in stdenv and want to verify tests.cc-wrapper.default, then it's 100 more rebuilds with current execline unless it's hacked around in those tests, just to fetch manpages etc. | 14:20:03 |
| emily | which we've hacked around in tests.cc-wrapper.default, but it just in general seems bad for a basic lib function that is trying to accomplish literally a NOP to pull in all that stuff, when it was only switched to execline in the first place because "well, it's already there so why duplicate it?". | 14:20:33 |
| emily | to which the answer is, now it means the bootstrap chain for basic tests is a bunch longer, unless we hack around it or strip down the closure | 14:20:57 |
| sterni | you don't need to use canExecute there, just don't test emulator if hostPlatform == buildPlatform if you really care about the speed of the tests | 14:20:58 |
| emily | but the whole point of having a NOP emulator is that you can just use it without needing to replicate that logic everywhere. | 14:21:24 |
| emily | (that wouldn't work for i686 anyway I think) | 14:21:36 |
| sterni | I think it's worse to have like weird code for no reason that relies on bootstrapping logic | 14:21:56 |
| sterni | that's always a recipe for having to debug some eval problem for a week down the road | 14:22:17 |
| emily | ok. then can we go back to just vendoring a 5-line C program? | 14:22:17 |
| emily | that would solve all the issues and be even fewer builds | 14:22:26 |
| emily | and execline can do whatever | 14:22:32 |
| sterni | no I'd say just use buildPackages.execline honestly, it's the simplest and cleanest | 14:22:48 |
| sterni | the problem just affects nixpkgs developers and we can just split the tests up, so you don't run the emulator tests if you're in a hurry, right? | 14:23:15 |
