 | Nixpkgs Stdenv | 226 Members |
| 74 Servers |
| Nixpkgs Stdenv | 226 Members |
| 74 Servers |
| Sender | Message | Time |
|---|---|---|
| 19 Nov 2024 | ||
 emily | ideally those would be split out into separate derivations or something and we'd integrate emulators at the Nix level though | 15:56:38 |
| emily | but that's a tall order when we haven't even separated out tests :/ | 15:56:46 |
 sterni | for that I think you can just depend on yourself from buildPackages | 15:56:49 |
| sterni | if your completions are target specific you deserve it | 15:57:11 |
| emily | doesn't really work for tests though (but admittedly emulation is complicated there too) | 15:57:39 |
| emily | I don't love the buildPackages solution since it basically doubles all your builds | 15:58:00 |
| sterni | you build that anyways… | 15:58:59 |
| emily | what do you mean? jujutsu certainly doesn't depend on buildPackages.jujutsu | 16:01:02 |
| emily | though if you mean in the sense that Hydra builds most things for common platforms then sure | 16:01:10 |
| emily | looks like the native emulator has been there since 9c8fd412248ad907eee7547b19bf3f7583d2c411, when the function was added in the first place | 16:06:02 |
| emily | anyway, hopefully everyone should be happy with the shell script, since it doesn't touch execline, doesn't add a C file, and doesn't add any non-trivial builds | 16:07:11 |
| emily | still seems like the man pages ought to be split out of execline for the unrelated reasons that were brought up, but it's not my package | 16:07:31 |
| sterni | yeah the execline situation is well… | 17:50:18 |
| sterni | one maintainer more or less unilaterally integrated them, but I guess no one felt strongly enough to start a row about it so far | 17:50:53 |
| emily | my patches are there if anyone wants them, but I guess they no longer have stdenv-related motivation 😅 | 17:53:50 |
| sterni | In reply to @emilazy:matrix.orgyeah… | 18:00:39 |
| sterni | sorry if I've been difficult :) | 18:01:14 |
| emily | eh, it's just a bunch of understandable but colliding priorities I think :) | 18:05:23 |
| emily | execline wants to not worry about its own closure size too obsessively, Nixpkgs tests want to be as cheap as possible to run, cross wants to not depend on execution of the host platform, tests need running, binaries want to dynamically generate things | 18:06:11 |
| emily | it's all an ugly mess but at least the simple decoupling should reduce some of the pressure points there | 18:06:39 |
| emily | I think in an ideal world we would have a cross setup where tests and generation of completions/introspection data/etc. are always in separate derivations that can be opted out of, and can run at the Nix level either through emulation or remotely on a (presumably underpowered for building) native machine | 18:07:50 |
| emily | but that's a massive project | 18:08:07 |
| sterni | also for that we would need to solve the binary cache problem™ since you'd probably need to have intermediate artifacts (post buildPhase) as a generic mechanism | 18:38:41 |
| sterni | which obviously causes somewhat of a space problem | 18:38:51 |
| emily | yes | 18:39:37 |
| emily | I just file every improvement above a certain level of architectural ambition as "TODO in my Nix redesign" | 18:39:57 |
| emily | which allows me to remain ruthlessly pragmatic without feeling like I'm betraying my fundamental values :p | 18:40:17 |
 p14 | emily: I’ve been thinking a bit about what you were saying about separation of interface vs implementation for CA builds. One concern is: if you switch out the implementation, should that not also require a rebuild of downstream software which uses the implementation during the build at least? I was thinking of the openssl case where ideally updating openssl doesn’t require a rebuild of the world, but as soon as you have a package which in checkPhase exercised the implementation of openssl, that package could be broken by the new implementation but would not have its tests run. I guess if you depend on the implementation in order to build (or test) then that would require passing the implementation in; and therefore would condition the build on the implementation. I also wonder if I am talking myself into the concept that testing would have to happen in a separate derivation, essentially, which consumes the implementation. | 19:32:34 |
| emily | it would have its tests run – tests would happen after the relinking stage | 19:33:06 |
| emily | you could avoid these being in serial by using something like Ninja's "validations" | 19:33:17 |