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

I'm assuming that some people are using a custom implementation for vendoring. (e.g. for some authentication logic IDK) and their logic assumes that cargoSetupHook expects an unpacked cargo vendor structure.
So I don't think we should unconditionally use fetch-cargo-vendor-util if we detect that cargoDeps is a directory.
We'd have to conditionally run our logic, only when we know we're using something that was generated by fetchCargoVendor
However, we can't really put any distinction marker files into vendor-staging, since that's a FOD.

But maybe I'm overthinking this.

Yes getting rid of the two steps would be healthier for easier overriding of hashes via overrideAttrs

Anyways, I have to go now... I'll be back in an hour or so, sorry!

In reply to @niklaskorz:matrix.org
@Toma I rebased + reran your treewide to resolve the merge conflicts, will also run nixpkgs-review for darwin and linux in a bit, but otherwise I think it’s good to go?

As discussed earlier, we were considering waiting until https://github.com/NixOS/nixpkgs/pull/423228 gets into stable so that we can do this treewide both on stable and master, to avoid much of the backporting issues.
Though, there hasn't been a staging-next-25.05 cycle since then...

So maybe we can deal with a few backporting conflicts until then.

idk, what do you think is better?