Added --generate-lockfile for generating a new lockfile

[UebelAndre]

This PR adds a new argument --generate-lockfile which will force a new lockfile to be generated.

CargoWorkspaceFiles was deleted

Cargo.toml and Cargo.lock were basically never used for anything other than finding the cargo workspace. It's simpler to pass around a Path and allow the underlying cargo command to handle finding the correct metadata.

--generate-lockfile

This will always generate a Cargo.raze.lock file which will take precedence over an existing Cargo.lock file. As a reminder, this file exists because to allow projects using binary_deps to have a lockfile that doesn't conflict with the standard lockfile. I'm hoping to one day delete the need for this file and standardize on the canonical Cargo.lock file, but for now, the use of Cargo.raze.lock makes the outputs of cargo-raze more consistent.

Running this command against the examples/remote/cargo_workspace example yields the following changes to the workspace

cargo_workspace % git status

On branch checksum
Your branch is up to date with 'origin/checksum'.

Changes not staged for commit:
  (use "git add/rm <file>..." to update what will be committed)
  (use "git restore <file>..." to discard changes in working directory)
	modified:   cargo/crates.bzl
	deleted:    cargo/remote/BUILD.addr2line-0.13.0.bazel
	modified:   cargo/remote/BUILD.atty-0.2.14.bazel
	deleted:    cargo/remote/BUILD.backtrace-0.3.53.bazel
	deleted:    cargo/remote/BUILD.cfg-if-0.1.10.bazel
	modified:   cargo/remote/BUILD.error-chain-0.10.0.bazel
	deleted:    cargo/remote/BUILD.getrandom-0.1.15.bazel
	deleted:    cargo/remote/BUILD.gimli-0.22.0.bazel
	modified:   cargo/remote/BUILD.hermit-abi-0.1.17.bazel
	deleted:    cargo/remote/BUILD.libc-0.2.79.bazel
	deleted:    cargo/remote/BUILD.object-0.21.1.bazel
	deleted:    cargo/remote/BUILD.ppv-lite86-0.2.9.bazel
	modified:   cargo/remote/BUILD.rand-0.7.3.bazel
	modified:   cargo/remote/BUILD.rand_chacha-0.2.2.bazel
	modified:   cargo/remote/BUILD.rand_core-0.5.1.bazel
	deleted:    cargo/remote/BUILD.rustc-demangle-0.1.17.bazel

Untracked files:
  (use "git add <file>..." to include in what will be committed)
	cargo/Cargo.raze.lock
	cargo/remote/BUILD.addr2line-0.14.1.bazel
	cargo/remote/BUILD.backtrace-0.3.55.bazel
	cargo/remote/BUILD.getrandom-0.1.16.bazel
	cargo/remote/BUILD.gimli-0.23.0.bazel
	cargo/remote/BUILD.libc-0.2.81.bazel
	cargo/remote/BUILD.object-0.22.0.bazel
	cargo/remote/BUILD.ppv-lite86-0.2.10.bazel
	cargo/remote/BUILD.rustc-demangle-0.1.18.bazel

no changes added to commit (use "git add" and/or "git commit -a")

Note the addition of cargo/Cargo.raze.lock here. cargo-raze will use this for subsequent runs. It's also worth noting that if no Cargo.lock or Cargo.raze.lock files exist, a Cargo.raze.lock file will be generated.

New warning for missing checksum

There's a new warning in the checks module that will print a warning for when a crates.io crate is missing a checksum:

With the following diff

diff --git a/examples/remote/cargo_workspace/Cargo.lock b/examples/remote/cargo_workspace/Cargo.lock
index 44494886..54cc7fa1 100644
--- a/examples/remote/cargo_workspace/Cargo.lock
+++ b/examples/remote/cargo_workspace/Cargo.lock
@@ -13,7 +13,7 @@ dependencies = [
 name = "adler"
 version = "0.2.3"
 source = "registry+https://github.com/rust-lang/crates.io-index"
-checksum = "ee2a4ec343196209d6594e19543ae87a39f96d5534d7174822a3ad825dd6ed7e"
+#checksum = "ee2a4ec343196209d6594e19543ae87a39f96d5534d7174822a3ad825dd6ed7e"

 [[package]]
 name = "ansi_term"

The following error is produced

Running Cargo Raze for cargo_workspace
WARNING: Packages are missing checksums, perhaps `cargo generate-lockfile` needs to be run in the current cargo workspace. Missing checksums: ["adler-0.2.3"]

[UebelAndre]

@acmcarther Hey, do you have time to take a look at this today? Would hugely appreciate it 🙏 😅

[acmcarther]

LG, but I'm still not completely clear why just using Cargo.lock doesn't work. Can you explain that again?

You said above

This will always generate a Cargo.raze.lock file which will take precedence over an existing Cargo.lock file. As a reminder, this file exists because to allow projects using binary_deps to have a lockfile that doesn't conflict with the standard lockfile. I'm hoping to one day delete the need for this file and standardize on the canonical Cargo.lock file, but for now, the use of Cargo.raze.lock makes the outputs of cargo-raze more consistent.

But I'm not clear why this "[allows] projects using binary_deps to have a lockfile that doesn't conflict with the standard lockfile". What happens if you just used Cargo.lock?

[UebelAndre]

LG, but I'm still not completely clear why just using Cargo.lock doesn't work. Can you explain that again?

Currently, binary dependencies are being added to manifests during the fetch phase of cargo-raze

cargo-raze/impl/src/metadata.rs

Lines 328 to 364 in 0cb6178

	/// Add binary dependencies as workspace members to the given workspace root Cargo.toml file
	fn inject_binaries_into_workspace(
	&self,
	binary_deps: Vec<String>,
	root_toml: &Path,
	) -> Result<()> {
	// Read the current manifest
	let mut manifest = {
	let content = fs::read_to_string(root_toml)?;
	cargo_toml::Manifest::from_str(content.as_str())?
	};
	// Parse the current `workspace` section of the manifest if one exists
	let mut workspace = match manifest.workspace {
	Some(workspace) => workspace,
	None => cargo_toml::Workspace::default(),
	};
	// Add the binary dependencies as workspace members to the `workspace` metadata
	for dep in binary_deps.iter() {
	workspace.members.push(dep.to_string());
	}
	// Replace the workspace metadata with the modified metadata
	manifest.workspace = Some(workspace);
	// Write the metadata back to disk.
	// cargo_toml::Manifest cannot be serialized direcly.
	// see: https://gitlab.com/crates.rs/cargo_toml/-/issues/3
	let value = toml::Value::try_from(&manifest)?;
	std::fs::write(root_toml, toml::to_string(&value)?).with_context(|| {
	format!(
	"Failed to inject workspace metadata to {}",
	root_toml.display()
	)
	})
	}

This will cause the lockfile to contain content not reproducible via canonical Cargo commands. To avoid any conflicts with things like rust-analyzer that might update the Cargo.lock file under certain circumstances, cargo-raze will take a Cargo.raze.lock file over the canonical Cargo.lock file. This keeps "cargo workspaces" clean for projects that follow the 'many-tomls' model.

Users can use Cargo.lock files without any problems, but until inject_binaries_into_workspace can be removed, I think it's better to maintain a separate lockfile. I think with the progress in rust-lang/rfcs#3028 we're getting closer to Cargo being able to handle binary dependencies first class and we won't need this tool to do anything unique anymore.

However, Maybe I can be smarter about detecting which lockfile is relevant, the custom Cargo.raze.lock file or the canonical Cargo.lock file based on the existence of binary_deps in the current RazeSettings? Your thoughts?

[acmcarther]

Given what you've said above, I prefer always using our weird cargo.raze.lock, rather than conditionally using it when we need to.