Can we have Cargo.lock in the repository?

[thoughtpolice]

This question was bound to come up but, basically, title.

In the quest to add a package to the Nix flake.nix file in the repo, which would allow people to consume or install Buck2 fairly easily, I have come to the cross roads where I need a committed Cargo.lock file for the build to work. The reason is pretty simple: Cargo's whole design requires the lockfile, not the Toml file, to be the deterministic source of truth. There is no guarantee cargo generate-lockfile will generate the same lockfile when run twice in a row, so a committed one is necessary if you want to e.g. keep a stable hash of all dependencies needed and downloading them, like Nix does. Assuming this exists, well, adding the Buck package to the flake file is easy!

But Meta doesn't use Cargo lockfiles, and there are reasons for that. But without getting into it: is this a hard rule? Could we add a Cargo.lock in the top-level directory, and start supporting it? Some other Meta projects such as Hermit for example have lockfiles, while Sapling doesn't — so I'm not sure how hard of a rule this is, or if both can be easily supported.

I don't think it needs to be like a hard blocker for pushing, obviously. Frankly the OSS CI build seems to fail a bit more than would be ideal, but that's life and I understand concerns about velocity, etc. :) But we could just:

• Commit it, keep it working on a best effort basis.
• Put it in the OSS CI build and make sure it gets built on every commit.
• If there are some intervening moments where things are broken, that's sometimes life.

I'm pretty sure at some point this is more or less going to be a requirement in the long run for non-Meta users, people will be very easy about bucking(!!) the trend here and generating their own lockfiles. We actually require this in Nixpkgs more or less too, so we're going to have to either help contribute one or ship one ourselves, eventually (like we already do for Sapling, and like I already do for buck2-nix.)

In the long run as Buck2 evolves and sees more outside usage, the best-effort CI policy can be reconsidered, stuff like that. And assuming this can be all worked out, I can easily submit a change for adding it soon. But I wanted to ask, since I figured if there isn't one already, that's a pretty good sign it should be discussed first...