Only if you pick out one point of the discussion. In the original issue, Restrict fixed-output derivations · Issue #2270 · NixOS/nix · GitHub , one of the main arguments of Eelco against buildRustPackage is:
Such impurities are bad for reproducibility because the dependencies on external files are completely implicit: there is no way to tell from the derivation graph that the derivation depends on a bunch of crates fetched from the Internet.
But the same argument applies equally to approaches where fetching is transparent (fromTOML + fetchurl), but the whole build is farmed out to a third-party tool like cargo. You do know what source tarballs are in the transitive closure, but the Nix expression does not encode the exact dependency graph and how the sources are built. This leads to the downsides I mentioned (no caching of dependent crates).
I am not sure what you are saying here 
. Almost every Rust package that we currently package is effectively one leaf package and tens or hundreds of interior packages (all the dependencies). With buildRustPackage we just pretend that the whole thing is one leaf package and lose many of the benefits of Nix (such as caching).
Contrast that with buildRustCrate (e.g. via crate2nix). Builds are typically blazingly fast because all the shared crates are only compiled once. Moreover, you get Nix expressions with properly defined dependency graphs. It’s how Nix is supposed to work.
@mic92 and @kolloch are working on making crate2nix more fit for use in nixpkgs:
- Source dependencies are not explicitly defined.
- Every builder retrieves the same sources over and over again, because dependencies are cached at the vendored-tarball level and not at the individual source level. So if two packages use the same version of the
libccrate, it is fetched over and over again. - It’s fragile. If upstream changes anything to the vendoring that cannot easily be normalized, all hashes break.