On Thu, Jul 17, 2025 at 3:30 PM brian m. carlson <sandals@xxxxxxxxxxxxxxxxxxxx> wrote: > > On 2025-07-17 at 20:32:18, Ezekiel Newren via GitGitGadget wrote: > > diff --git a/rust/Cargo.lock b/rust/Cargo.lock > > new file mode 100644 > > index 000000000000..fb1eac690b39 > > --- /dev/null > > +++ b/rust/Cargo.lock > > @@ -0,0 +1,14 @@ > > +# This file is automatically @generated by Cargo. > > +# It is not intended for manual editing. > > +version = 4 > > + > > +[[package]] > > +name = "interop" > > +version = "0.1.0" > > + > > +[[package]] > > +name = "xdiff" > > +version = "0.1.0" > > +dependencies = [ > > + "interop", > > +] > > I would prefer that we not check in Cargo.lock in Git. Part of the > reason is that it changes across versions and so building with a > different version of the toolchain can update the file. This goes against what I think is best practices. Don’t we need Cargo.lock to audit and debug platform specific issues, and to ensure reproducibility? Without Cargo.lock, we might get different results one minute to the next if one of our dependencies releases a new version. Checking in Cargo.lock aligns with Cargo’s documented best practices (https://doc.rust-lang.org/cargo/faq.html#why-have-cargolock-in-version-control). > In addition, as I mentioned downthread, because our intention is to > support the Debian stable toolchain for a year after the new stable > release, unless we are exceptionally careful about dependencies, we may > end up with a case where distros need to use older dependencies patched > for security but other users may want to update the versions to newer > dependencies with security fixes but that do not work on our pinned Rust > version. We can't possibly satisfy both sets of people if we pin > dependencies in Cargo.lock, so we probably want to avoid checking it in > and ignore it instead. I understand your concern and I agree that this could become a problem. I’m totally flexible on which rust version should be used, but without Cargo.lock checked in we lose the ability to audit why a build failed. I think that this will be a pain point, but numbing that pain means we can’t solve intermittent problems due to dependencies in the future. > -- > brian m. carlson (they/them) > Toronto, Ontario, CA
