cargo publish error

[baoyachi]

Problem

when I exec cargo publish command, casued detail error:

~ cargo publish
...
error: failed to verify package tarball

Caused by:
  Source directory was modified by build.rs during cargo publish. Build scripts should not modify anything outside of OUT_DIR.
  Added: /Users/baoyachi/github/nyx/target/package/nyx-space-2.0.0-alpha/Cargo.lock

  To proceed despite this, pass the `--no-verify` flag.

See detail:https://github.com/nyx-space/nyx/actions/runs/5080952451/jobs/9130014940

The nyx crates git ignore file add Cargo.lock. But Looking through the cargo source code, I found that there is a problem that the comparison of two values is not the same. The pkg_fingerprint in front does not have Cargo.lock digest, but the ws_fingerprint in the back contains Cargo.lock. But our current project git ignores the Cargo.lock file, is there a bug?

https://github.com/rust-lang/cargo/blob/6956c04ec9/src/cargo/ops/cargo_package.rs#L842-L886

Steps

No response

Possible Solution(s)

No response

Notes

No response

Version

➜  ~ cargo version --verbose
cargo 1.69.0 (6e9a83356 2023-04-12)
release: 1.69.0
commit-hash: 6e9a83356b70586d4b77613a6b33f9ea067b9cdf
commit-date: 2023-04-12
host: aarch64-apple-darwin
libgit2: 1.5.0 (sys:0.16.0 vendored)
libcurl: 7.88.1 (sys:0.4.59+curl-7.86.0 system ssl:(SecureTransport) LibreSSL/3.3.6)
os: Mac OS 13.4.0 [64-bit]

Tracing issue: baoyachi/shadow-rs#135

[weihanglo]

It is that in shadow-rs cargo metadata and cargo tree generated Cargo.lock. I would suggest not doing so as it modifies the source being packaged.

Ref: https://github.com/baoyachi/shadow-rs/blob/618e28af4d3d908a55c203038e8eb1ebc27508f7/src/env.rs#L109-L121

[baoyachi]

@weihanglo Thx.I see

[weihanglo]

This might be relevant to your use case #5707, in terms of providing an alternative path to Cargo.lock. However, It is about reading a lockfile not writing. For writing, I feel like it is less likely to be done since I haven't yet seen such a use case.

At this moment I think delete Cargo.lock after running those command could help maybe?

Going to close this as it's more like an issue should be solved on user side. If this is wrong, please tell us. Thank you!