| 18 Nov 2024 |
 sterni | emily: I don't get why we aren't using env or something instead of execline, surely coreutils or busybox are better optimised w.r.t. closure/bootstrapping? | 15:11:53 |
 emily | IIRC env doesn't work because of CLI arguments or something. https://github.com/NixOS/nixpkgs/pull/324071 originally just used a tiny inline C program but got bikeshedded into using execline because it's there | 15:12:30 |
| emily | I would be okay just doing the tiny inline C program thing | 15:12:35 |
| emily | right, we can't do env -- because we want it to be a binary path rather than an argv | 15:12:53 |
| emily | though some of the other things in there will already break if you give them options so maybe we should be doing wrappers of some kind anyway | 15:13:10 |
| emily | the advantage of our own tiny C program is that it inherently doesn't depend on fetching. | 15:14:08 |
| sterni | It's a bit silly that we can't really return the empty string. | 23:55:21 |
| 19 Nov 2024 |
| emily | yeah. well, it makes sense that we want something that's usable as an argv[0] | 00:08:01 |
| emily | I lean towards just vendoring the C program, but if that doesn't fly I feel like my PR is an improvement. | 00:08:29 |
|  @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 |
