4 ms·

Plenty of projects ship binaries without a problem. Nearly every Linux distribution, for example. What’s special about Rust in that binaries for dependencies ar

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?

monocasa 3y ago
> Nearly every Linux distribution, for example. What’s special about Rust in that binaries for dependencies are a problem? 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.
- dlisboa 3y ago
  Can’t you “vendor” the crate and compile it yourself? Much like cargo does with workspaces, setting the local path to it. I’m still learning the Rust environment but usually vendoring is what you do when you want full control.
  - monocasa 3y ago
    The binary is in the package you would be vendoring. That's half the problem; the maintainer put binaries in something consumers treat as a source archive.
dcan 3y ago
Plenty of projects ship a) reproducible and b) application binaries. 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.
Nullabillity 3y ago
Yes, binary packages are a bad idea everywhere. Usually, their justification comes from two sources: 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.
- deleted 3y ago
  [deleted]
layer8 3y ago
Yeah, the whole Java ecosystem for example is built on binary dependencies, and is a very healthy one in spite of that. The same holds for C#/.NET and Apple frameworks. Having the source available, or preferably open, and preferably with reproducible builds, is of course desirable.
- silon42 3y ago
  Except that Java is regularly decompiled by people's IDEs.

monocasa 3y ago

> Nearly every Linux distribution, for example. What’s special about Rust in that binaries for dependencies are a problem? 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.

dlisboa 3y ago
Can’t you “vendor” the crate and compile it yourself? Much like cargo does with workspaces, setting the local path to it. I’m still learning the Rust environment but usually vendoring is what you do when you want full control.
- monocasa 3y ago
  The binary is in the package you would be vendoring. That's half the problem; the maintainer put binaries in something consumers treat as a source archive.

dcan 3y ago

Plenty of projects ship a) reproducible and b) application binaries. 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.

Nullabillity 3y ago

Yes, binary packages are a bad idea everywhere. Usually, their justification comes from two sources: 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.

deleted 3y ago
[deleted]

layer8 3y ago

Yeah, the whole Java ecosystem for example is built on binary dependencies, and is a very healthy one in spite of that. The same holds for C#/.NET and Apple frameworks. Having the source available, or preferably open, and preferably with reproducible builds, is of course desirable.

silon42 3y ago
Except that Java is regularly decompiled by people's IDEs.