NixOS needs Cargo.lock to be deterministic about capnproto-rust

[dwrensha]

According to the Cargo docs, Cargo.lock should only be checked in for an executable. capnproto-rust is a library, not an executable.

My understanding is that checking in a Cargo.lock file would make life more difficult for me, as that file would continually get out-of-date, and having it checked-in wouldn't actually have any effect on anyone using capnproto-rust, because they will all have top-level Cargo.lock files that ignore my Cargo.lock. Am I missing something here?

cc'ing @maurer, because he may know about this than I do.

[sjmackenzie]

@dwrensha thanks for the reply, we're busy trying to get better support for NixOS and Rust. It would seem that the current implementation has a bit of a problem.

As per this comment: NixOS/nixpkgs#8186 (comment) it seems the Cargo.lock isn't needed. @wizeman do you have any suggestions on a way forward? (probably best to continue on NixOS/nixpkgs#8186) - I'll close this issue.

[sjmackenzie]

Yeah, it seems common nixos practice to commit the lockfiles for rust libraries, as nix demands determinism, and it get the determinism from the lock files. So instead of me having to fork each rust repo it would be ever so helpful if you simply committed the lockfiles. Totally your choice.

[wizeman]

@sjmackenzie Just to be clear, I don't think it's common practice for NixOS to commit lockfiles for Rust libraries. NixOS will work just fine if only Rust programs have lockfiles, which is what the Rust community recommends.

There is, however, an exception when Rust libraries need to be themselves a build product (i.e. a package). This can happen, for example, when a Rust library exposes a C ABI and is meant to be used by non-Rust programs.

In this case, since we need to create a binary package out of a Rust library (i.e., there is no Rust program with a lockfile that we can use), then we do need a lockfile for the Rust library, otherwise the build inputs (and therefore, outputs) would be non-deterministic.

[sjmackenzie]

@wizeman indeed, though I'm seeing more commits like this:
https://github.com/pijul/pijul/commit/97a7fb736b35166bf3129b4014e0df161e056bf5

nevermind!