Check in Cargo.lock

[dtolnay]

I see that this was discussed previously in #10 and #30 but as far as I can tell, it was never coherently explained why cargo-update needs to do this differently.

Synopsis of previous thread and some points of my own:

• The Cargo FAQ is very explicit about when Cargo.lock is supposed to be checked in. It writes:

  It is recommended that all binaries check in their Cargo.lock.

  The reasons are explained in the link.

• The rebuttal to this point in Add Cargo.lock to the repository (if there exist one) #10 (comment) was:

  <nabijaczleweli> But this is a library

• After being pointed out that the crate does contain binaries, the follow-up was:

  <nabijaczleweli> think of the exec like an example, which it basically is (and should be)

  While you may see it this way, I haven't found any evidence that any code anywhere uses cargo-update as a library. On crates.io there are zero crates that depend on cargo-update. On GitHub there are zero Cargo.toml manifests that depend on cargo-update. Everybody only uses the binaries.

• In Add Cargo.lock to repository #30 (comment) it was pointed out that adding Cargo.lock does not affect how this crate is used as a library. Quoting again from the same Cargo FAQ:

  Users dependent on the library will not inspect the library’s Cargo.lock (even if it exists).

  Cargo will use the lockfile for building the binary, while crates that depend on the library will ignore the lockfile. This means we get all the benefits of shipping a Cargo.lock with an exclusively binary crate.

[dtolnay]

cc @mzji and @ishitatsuyuki in case I got anything wrong

[nabijaczleweli]

The argument list

Okay, let's go top-down.

cargo-update needs to do this differently

It's not just cargo-update, it's every crate produced by me. Why? Stay tuned.

The Cargo FAQ [...]

Yes, that FAQ was written by some smart people and I will not undermine their authority, however:

[...] used to provide deterministic builds [...]

Here's my view on this: you don't really want fully-deterministic builds (where deterministic is defined as "constant up to a certain level of abstraction across all implementers thereof", where that level of abstraction sits somewhere slightly above user-dependent paths but slightly below other paths and system configuration) – what you (I?) want is the "best" version of every dependency, without having it explicitly governed by some (possibly very outdated) "ground truth". Bonus points: the Rust ecosystem tends to employ SemVer and therefore, maybe not guarantees, but borderline so, that patch version variances will ensure compilation and correctness of the code to an increasing degree (because it's quite safe to assume that an increase in version is proportional to an increase in correctness and other positive factors).

Synopsis: benefit of full determinism is naught, benefit of non-determinism is nonnegative.

[...] it is recommended that all binaries [...]

[...] rebuttal to this point in #10 (comment)

Again, this is not primarily a binary (or that's how I (don't? (English is weird)) view it). Why? Stay tuned.

[...] crate does contain binaries [...]

(Day-(which is to say: anal)-nab would devil's advocate they're sources to binaries and not binaries per se, but I'm tired so I won't.)

I haven't found any evidence that any code anywhere uses cargo-update as a library.

cargo-install-update and cargo-install-update-config do, for example. But let's not dwell on the header.

zero crates that depend on cargo-update
zero Cargo.toml manifests that depend on cargo-update

Two fundamental mistakes were committed in looking for said evidence:

• crates.io (i.e. the main registry) contains all crates (i.e. cargo projects) in existence, and
• GitHub is the only place code can exist.

(Also I don't think that that "dependent crates" counter is quite accurate, but v0v.)

Therefore that evidence is based on incorrect assumptions (laid forth above) and therefore exhibits bias that makes it unusable.

Everybody only uses the binaries

Overgeneralisation (exemplified, e.g., by the fact, that around 13k downloads (calculating however many individual entities doing those downloads is left as an exercise to the reader) have used the library).

Cargo.lock does not affect how this crate is used as a library

Well, that's great, innit? You get no lack-of-upsides of having lockfile either way.

This means we get all the benefits of shipping a Cargo.lock with an exclusively binary crate.

Something's wrong with assumptions or interpretation here, again (and yes, it's "exclusively binary").

Additional commentary

As we can conclude from section 1, a ground-truth lockfile has no benefits, while lack thereof can exhibit a non-negative benefit set.

Here comes the slightly more philosophical part (don't worry, I do real philosophy): ever since a certain point (determining which crate was the first is left as an exercise to the reader), which really should have been day 1, but it took a while to transition from my previous C++-based mindset, my crates (and, after that point, other things) are just more-or-less lightweight "interfaces" (there's probably a better word for that but I'm tired, Polish, and bad at English) to the libraries. Nothing more, how I view this, than a usage example, or a "here's how I do it" (also a badly broadcast subliminal challenge to the reader – "What can you do with it? Can you break it?" (I also do believe that a great part of learning and testing any system is breaking it)). That is why, I do wholeheartedly believe, the "binary" parts of this, and other, crates are just a nice helpful sprinkle on top (like this example, for example, just more-helpfully first-classed).

The human, software, and maintenance aspect

(This part is written from the perspective of maintainer-(or day-)nab, who has a short temper and gets vulgar to get his point across better. Hide your children.)

A lockfile is just more garbage automatically generated by the build system with no real added value (it's just a derivative of Cargo.toml). It has to be actively maintained and easy to just plain forget about (but slim, what if a patch update, renders this broken? Well same would happen to literally everyone else using the damn thing and I'm not the one to catch shit for it (Hellooooo, rust-lang/futures-rs#160! How ya doin'?)).

Also, it's an intermediate build file, like, dunno, the build directory in nabijaczleweli.xyz-dev – a halfway finished product that you really don't push, because it's just a derivative of the build files, while the full product is a second-order derivative thereof (compare: target/{debug,release}/{build,deps,et caetera}). IOW you derive build files into intermediate files, then intermediate files into the product (there has to be a better word for this, too, but you know what I mean).

Afterword

Was that clear and typo-free? I doubt it, since I've only been using English fluently for the last 5 years and am still relatively schite at it, so ask, correct, do your worst. Debating is fun!

[Br1ght0ne]

I second the request to add Cargo.lock to the tree. I'm maintaining a package for Nix/NixOS, and Cargo.lock needs to be patched in.