4 ms·

>Are there any other languages that focus on "reproducible builds" for packages? I think you misunderstand what "reproducible" means in the context of OP, but

>Are there any other languages that focus on "reproducible builds" for packages? I think you misunderstand what "reproducible" means in the context of OP, but I will try to answer your question in the context of Rust. When you upload a crate to crates.io it gets uniquely identified by its cryptographic hash. It's not possible to replace code for an already uploaded crate version. Now, when you get dependencies for your build you may get newer (semver-compatible) version, but you always can retrieve the older version. To prevent such automatic updates, Rust applications often commit Cargo.lock to their repos, which contains hashes of all dependencies. So unless you manually run `cargo update` you will get exactly the same dependency tree, which with some minor build tweaks makes properly reproducible builds possible. Arguably, it's a much better system than relying on VCS as Go does.

pabs3 4y ago
I've seen Rust crates where the code was generated from a Python script and some other data and neither of those things are in the crate, which is potentially a license violation for copyleft crates. Or crates where the tests were in VCS but not in the crate. Or there were prebuilt files in the crate. I think always going with the VCS is a better option.
- newpavlov 4y ago
  >code was generated from a Python script and some other data and neither of those things are in the crate Yes, it's (IMO unfortunately) possible to have non-reproducible code generation during compile time. The most prominent example is code generation based on DB schema. But such cases are quite rare and "going with the VCS" does not help here in any way. If you mean that Rust code gets generated by a Python script and then gets uploaded to crates.io without the "origin" scrips, then I don't see any problems here. >Or crates where the tests were in VCS but not in the crate Tests are not used in building the final application, so they are irrelevant for reproducibility. >prebuilt files in the crate While I think it's a bad practice (though I haven't seen such crates myself), it does not hinder build reproducibility.
  - pabs3 4y ago
    > "going with the VCS" does not help here in any way. It does, because then you can run the build process yourself from the real source files and check if it is reproducible. > If you mean that Rust code gets generated by a Python script and then gets uploaded to crates.io without the "origin" scrips, then I don't see any problems here. Right. The problem is there is no source in the crate, just generated Rust code, so you can't know if the build process to create that Rust code is reproducible or not. > While I think it's a bad practice (though I haven't seen such crates myself), it does not hinder build reproducibility. The problem is that these are prebuilt files and so your build process is just copying them not building them, so you can't know if the build of them is reproducible.
    - newpavlov 4y ago
      I think your definition of "reproducible" is somewhat different from the one usually used. Reproducibility means that by running build process you always get the same binary, nothing more, nothing less. Having a bunch of generated Rust code or blobs in a published crate makes it harder to review (which is why I consider it a bad practice), but such crate is still completely reproducible.
      - pabs3 4y ago
        The crate might be reproducible, but the build process used to create the crate is not reproducible. Every build process should be reproducible, even the ones that are used to create the crates themselves.
        simiones 4y ago
        There is no build system that can guarantee that though - Go's certainly doesn't, with its use of go:generate tags that can easily do system-dependent things at build time and ability to link C lib blobs.
- bombolo 4y ago
  You can put binary files on git as well… if the developer is clueless there is no fix. It would be good to flag bad packages but it's impossible.
  - pabs3 4y ago
    Yes, you have to audit the VCS for non-source files as well as verifying reproducibility.

pabs3 4y ago

I've seen Rust crates where the code was generated from a Python script and some other data and neither of those things are in the crate, which is potentially a license violation for copyleft crates. Or crates where the tests were in VCS but not in the crate. Or there were prebuilt files in the crate. I think always going with the VCS is a better option.

newpavlov 4y ago
>code was generated from a Python script and some other data and neither of those things are in the crate Yes, it's (IMO unfortunately) possible to have non-reproducible code generation during compile time. The most prominent example is code generation based on DB schema. But such cases are quite rare and "going with the VCS" does not help here in any way. If you mean that Rust code gets generated by a Python script and then gets uploaded to crates.io without the "origin" scrips, then I don't see any problems here. >Or crates where the tests were in VCS but not in the crate Tests are not used in building the final application, so they are irrelevant for reproducibility. >prebuilt files in the crate While I think it's a bad practice (though I haven't seen such crates myself), it does not hinder build reproducibility.
- pabs3 4y ago
  > "going with the VCS" does not help here in any way. It does, because then you can run the build process yourself from the real source files and check if it is reproducible. > If you mean that Rust code gets generated by a Python script and then gets uploaded to crates.io without the "origin" scrips, then I don't see any problems here. Right. The problem is there is no source in the crate, just generated Rust code, so you can't know if the build process to create that Rust code is reproducible or not. > While I think it's a bad practice (though I haven't seen such crates myself), it does not hinder build reproducibility. The problem is that these are prebuilt files and so your build process is just copying them not building them, so you can't know if the build of them is reproducible.
  - newpavlov 4y ago
    I think your definition of "reproducible" is somewhat different from the one usually used. Reproducibility means that by running build process you always get the same binary, nothing more, nothing less. Having a bunch of generated Rust code or blobs in a published crate makes it harder to review (which is why I consider it a bad practice), but such crate is still completely reproducible.
    - pabs3 4y ago
      The crate might be reproducible, but the build process used to create the crate is not reproducible. Every build process should be reproducible, even the ones that are used to create the crates themselves.
      - simiones 4y ago
        There is no build system that can guarantee that though - Go's certainly doesn't, with its use of go:generate tags that can easily do system-dependent things at build time and ability to link C lib blobs.
bombolo 4y ago
You can put binary files on git as well… if the developer is clueless there is no fix. It would be good to flag bad packages but it's impossible.
- pabs3 4y ago
  Yes, you have to audit the VCS for non-source files as well as verifying reproducibility.