Dirty Cargo.lock file reported on package/publish even if in .gitignore

[DaniPopes]

Problem

Cargo throws an error when trying to publish/package alloy-rs/core on nightly (cargo 1.87.0-nightly (6cf826701 2025-03-14)), while it works fine on stable (1.85).

This breaks our cargo-release workflow, and I don't really understand this error since Cargo.lock is not dirty, is in .gitignore, and also adding it to Cargo.toml package.exclude doesn't help.

Bisected to nightly-2025-03-11 -> rust-lang/rust#138200 -> probably #15276.

Steps

cd /tmp
git clone https://github.com/alloy-rs/core.git alloy-core
# git checkout 5d9b4f22a9091749e87d89058185dd8cf5a03fa2
cd ./alloy-core

args=(package --list)
# No Cargo.lock
cargo +stable "${args[@]}"  # OK
cargo +nightly "${args[@]}" # OK

# Generate Cargo.lock, but still ignored by git
cargo generate-lockfile
cargo +stable "${args[@]}"  # OK
cargo +nightly "${args[@]}" # Fails with:

error: 1 files in the working directory contain changes that were not yet committed into git:

Cargo.lock

to proceed despite this and include the uncommitted changes, pass the `--allow-dirty` flag

Possible Solution(s)

No response

Notes

No response

Version

cargo 1.87.0-nightly (6cf826701 2025-03-14)

[weihanglo]

Thanks for the report and the reproducible steps!

since Cargo.lock is not dirty, is in .gitignore, and also adding it to Cargo.toml package.exclude doesn't help.

The lock file is not dirty in the sense of calling the plain git status I gueses? However, Cargo checking the VCS status is more like git status --ignored --untracked-files=all

And the lockfile indeed get packaged into your final .crate tarball. It is a behavior you cannot opt-out except using the new --exclude-lockfile. However there is indeed a bug that with --exclude-lockfile is present, cargo pacakge should not check whether lockfile is dirty or not.

[weihanglo]

There are some nuances.
We check lockfile's VCS status if the lockfile is ouside the current package root. That means a non-workspace Cargo package will not have this VCS check. I don't think it is good that we have diverged behaviors on this. To make the behavior aligned, we have two options:

• Don't check lockfile's VCS status at all, since we don't do that for non-workspace package.
• Check also for non-workspace package.

The latter might be risky. People may have already excluded or gitignore'd the lockfile. Changing that means it will start breaking more workflow. Although we've talked about expanding it to checking the entire workspace, I'd rather not do that at this moment. Also, we seemed to settle on checking mainfest but didn't really discuss much about lockfile.