In reply to @rosscomputerguy:matrix.org
pkgsLLVM is a good way

In reply to @emilazy:matrix.org
not for an individual package in Nixpkgs though?

In reply to @glepage:matrix.org

Looks like rustfmt is broken on x86_64-darwin on nixos-25.05:

https://buildbot.nix-community.org/#/builders/2847/builds/5266/steps/1/logs/stdio (from Nixvim CI)

I think we can agree that fetchCargoVendor being a two step construction is not very good for the cache.
Now, we could move the calling of the "fetch-cargo-vendor-util create-vendor" into cargoSetupHook, but that would create a dependency on fetch-cargo-vendor-util for every rust package.

Now I think I came up with a pretty clever workaround, which keeps the two layers, but makes the non-FOD layer essentially just an empty derivation except a binary that you can run to start the unpacking process.
This way we just have to detect if that unpacking binary is present in cargoDeps inside cargoSetupHook and then call it.

Though, this would make it so that we can't "easily" get derivation with the vendored dependencies unpacked from the tarball.
But, we could provide a passthru.vendorFetched (things in passthru don't get build by CI) which just runs the unpacking logic into "$out"

(Also, I put in a symlink into the non-FOD part for vendorStaging for easier access)

I made a very rudimentary POC: https://github.com/NixOS/nixpkgs/pull/427815

Note: I did not take into consideration cross/splicing

What do you all think?

90% of Rust packages will already have that dependency and it's just a lightweight Python script, yeah?