Plenty of projects ship binaries without a problem. Nearly every Linux distribution, for example. What’s special about Rust in that binaries for dependencies are a problem?
Also, for the “why” - is it just the very slow build times for Rust?
Also, for the “why” - is it just the very slow build times for Rust?
serde-derive is a macro that is used in the compilation of projects. The way the developers have implemented it, when you build a project _from source_, it pulls and executes a binary blob against your code.
The binary in serde-derive is not reproducible (at least, there is no published hash and other users haven't been able to compile the same binary on their computers), and saves a very minor amount of time - serde-derive has to be compiled once per project per compiler version, unless you delete your dependencies.
The inability to opt out of running a non-reproducible binary library just to build code. This isn't just devs complaining, it's against several large orgs security policies.
> Also, for the “why” - is it just the very slow build times for Rust?
It's an initial build time thing. It makes no difference except after a full clean or fresh build.
I’m still learning the Rust environment but usually vendoring is what you do when you want full control.
1. Users may not have the correct build toolchain installed. (Mostly relevant for end-user applications, or native FFI modules.)
2. Building every package from source is slow.
Neither justification makes sense for serde-derive. For 1, serde-derive is just regular Rust code, built by their regular Rust toolchain. You already need to have the toolchain installed to use it! Hell, you need the same toolchain to build the wrapper library for the binary! For 2, serde-derive has a tiny dependency tree, and all of those are likely to be shared by any other proc macros the user depends on anyway, so the only thing you're skipping is... compiling serde-derive itself.