| 21 May 2025 |
|  @michael.zeagler:matrix.org joined the room. | 19:15:40 |
|  @bloxx12:matrix.org left the room. | 21:30:01 |
| 22 May 2025 |
 Toma | I'm mostly happy with fetchCargoVendor, though I worry about the impact on the cache:
every time a dependency of fetchCargoVendor changes, the non-FOD part needs to be re-cached, which can accumulate, and take up quite a lot of storage.
I wish there was a way to force hydra to not cache certain packages.
There is meta.hydraPlatforms = [], but AIUI it would only disable building it if it was directly built by hydra, but since it's a dependency of a package that is not disabled on hydra, it will get built and cached anyway...
I guess this could also be handled by content-addressed derivations...
Note: there are >2000 rust-based packages in nixpkgs currently
Question 1: What do you all think, how bad is this problem?
Question 2: How does one check how much storage a certain derivation takes up cached?
| 00:15:18 |
 emily | you can fetch the NAR | 09:00:12 |
| emily | shouldn't the non-FOD part mostly just be a bunch of symlinks? | 09:00:22 |
| emily | Alyssa Ross: do you have a preference between the diffs of https://github.com/NixOS/nixpkgs/pull/408710/files and https://github.com/NixOS/nixpkgs/pull/407790/files? they both fix pkgsStatic.buildPackages.rustc on Darwin, and they'll both leave some other cases unavoidably silently weird/broken (I think maybe slightly different cases between them). the original PR no longer depends on pkgsStatic. it's a bit more noisy but saves a rustc build. the other one is a smaller diff / fewer moving parts, but the ordering change is sort of unprincipled (albeit I think likely to make the build go through in strictly more cases than the status quo) | 09:02:30 |
 Alyssa Ross | I don't think I mind either | 09:06:36 |
| Alyssa Ross | I'd still really like to see the custom target specs eventually | 09:06:50 |
| Alyssa Ross | Consider them both acked | 09:06:59 |
| emily | me too, but cleaning up Rust is more work than I have the capacity for right now :( | 09:08:32 |
| emily | honestly we should really build std in a separate derivation always, I think | 09:08:40 |
| emily | and with the right platform triples | 09:08:43 |
| emily | rather than building a "rustc" that is actually just the target platform std | 09:08:54 |
| Alyssa Ross | IIRC @Ericson2314:matrix.org didn't think it was possible some time in the past | 09:10:08 |
| emily | why not? it's exactly what fastCross does, right? | 09:11:25 |
| emily | like fastCross could just not link in the rustc in installation phase, and swizzle around the targets that it passes, and then we could wrap them together later | 09:12:09 |
| emily | I guess the problem is that the non-cross compiler would still want to build the target std | 09:12:28 |
| emily | -Zbuild-std at least helps… | 09:12:39 |
 K900 | One day we'll have cargo-std-aware | 09:13:08 |
| emily | patch Rust to accept -Zbuild-std on stable, do separate-Rust-crate-packaging, make std one of them 🙃 | 09:13:14 |
| K900 | One day | 09:13:15 |
| emily | it'll be awful with the current Rust packaging scheme. because we would build std for every single application | 09:13:38 |
| emily | oh, I guess not because the FOD is compressed, right? Toma: why do we compress the FOD again? | 12:08:43 |
| emily | anyway, maybe we could move the unpacking of the FOD into the actual Rust package build? | 12:08:54 |
| Alyssa Ross | We'd need to do fetchCargoVendor2 for that | 12:13:56 |
| Toma | It is compressed, because it is how they are downloaded, and it is also not uncompressed so that we don't have file system case sensitiveness bite us with different hashes | 12:13:59 |
| Alyssa Ross | (Which doesn't mean we shouldn't) | 12:14:06 |
| Alyssa Ross | ah right | 12:14:12 |
| emily | fair | 12:16:26 |
| Toma | In reply to @tomasajt:matrix.org
It is compressed, because it is how they are downloaded, and it is also not uncompressed so that we don't have file system case sensitiveness bite us with different hashes Also, just in general, the goal was to have the dumbest possible FOD logic so that under no circumstance will the hash break. | 12:16:29 |
