!FBuJyWXTGcGtHTPphC:nixos.org

Nix Rust

684 Members
Rust154 Servers

You have reached the beginning of time (for this room).

SenderMessageTime
22 May 2025
@tomasajt:matrix.orgToma

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
@emilazy:matrix.orgemilyyou can fetch the NAR09:00:12
@emilazy:matrix.orgemilyshouldn't the non-FOD part mostly just be a bunch of symlinks?09:00:22
@emilazy:matrix.orgemily 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
@qyliss:fairydust.spaceAlyssa RossI don't think I mind either09:06:36
@qyliss:fairydust.spaceAlyssa RossI'd still really like to see the custom target specs eventually09:06:50
@qyliss:fairydust.spaceAlyssa RossConsider them both acked09:06:59
@emilazy:matrix.orgemilyme too, but cleaning up Rust is more work than I have the capacity for right now :(09:08:32
@emilazy:matrix.orgemily honestly we should really build std in a separate derivation always, I think 09:08:40
@emilazy:matrix.orgemilyand with the right platform triples09:08:43
@emilazy:matrix.orgemily rather than building a "rustc" that is actually just the target platform std 09:08:54
@qyliss:fairydust.spaceAlyssa Ross IIRC @Ericson2314:matrix.org didn't think it was possible some time in the past 09:10:08
@emilazy:matrix.orgemily why not? it's exactly what fastCross does, right? 09:11:25
@emilazy:matrix.orgemily 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
@emilazy:matrix.orgemily I guess the problem is that the non-cross compiler would still want to build the target std 09:12:28

Show newer messages

Back to Room ListRoom Version: 6