Currently, pkgbuild:::sources tracks many files under src/, but it ignores Cargo.lock. The practical advice is generally that Cargo.lock ought to be tracked (via version control) in the case of a binary, and not in the case of a library. That's because you cannot cargo install a library. But a rust crate embedded in an R package is regarded as a binary in this instance, as we can install an r-package. Cargo.lock helps with tracking dependencies, and aid in reproducible builds, and also it is something that changes irrespective of rust crates' source files .rs, and the Cargo.toml file. A lockfile is changed through a call to cargo update for instance. See https://doc.rust-lang.org/cargo/commands/cargo-generate-lockfile.html for details.
For now, to circumvent the lack of rebuilding behaviour through devtools (facilitated by pkgbuild) one may write this in the DESCRIPTION file:
Config/build/extra-sources: src/rust/Cargo.lock
I would love it if pkgbuild:::sources were changed so it would also include Cargo.lock files.
Currently,
pkgbuild:::sourcestracks many files undersrc/, but it ignoresCargo.lock. The practical advice is generally thatCargo.lockought to be tracked (via version control) in the case of a binary, and not in the case of a library. That's because you cannotcargo installa library. But a rust crate embedded in an R package is regarded as a binary in this instance, as we can install an r-package.Cargo.lockhelps with tracking dependencies, and aid in reproducible builds, and also it is something that changes irrespective of rust crates' source files.rs, and theCargo.tomlfile. A lockfile is changed through a call tocargo updatefor instance. See https://doc.rust-lang.org/cargo/commands/cargo-generate-lockfile.html for details.For now, to circumvent the lack of rebuilding behaviour through
devtools(facilitated bypkgbuild) one may write this in theDESCRIPTIONfile:I would love it if
pkgbuild:::sourceswere changed so it would also includeCargo.lockfiles.