Regression: git ignored Cargo.lock prevents cargo publish

[DoumanAsh]

Problem
git ignored Cargo.lock prevents cargo publish

> cargo publish
    Updating crates.io index
error: 1 files in the working directory contain changes that were not yet committed into git:

Cargo.lock

Steps

1. put Cargo.lock into gitignore like *.lock
2. cargo publish

Possible Solution(s)
This is likely a regression, because it was ok before 1.39
Should be reverted back

Notes

Output of cargo version:
cargo 1.39.0 (1c6ec66 2019-09-30)

[ehuss]

Thanks for the report, this has been fixed in 1.40 via #7448.

[Michael-F-Bryan]

I don't believe #7448 fixed this. I'm still getting the above error on nightly cargo.

Steps to reproduce:

$ cargo --version --verbose
cargo 1.42.0-nightly (6e1ca924a 2020-01-06)
release: 1.42.0
commit-hash: 6e1ca924a67dd1ac89c33f294ef26b5c43b89168
commit-date: 2020-01-06
$ rustc --version --verbose
rustc 1.42.0-nightly (859764425 2020-01-07)
binary: rustc
commit-hash: 85976442558bf2d09cec3aa49c9c9ba86fb15c1f
commit-date: 2020-01-07
host: x86_64-unknown-linux-gnu
release: 1.42.0-nightly
LLVM version: 9.0

$ cd /tmp
$ git clone https://github.com/Michael-F-Bryan/arcs
$ cd arcs/arcs
$ git clone 49887a61254003257cc61120cb4237778e89f243
$ cargo publish --dry-run
    Updating crates.io index
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

If it makes any difference, the crate is in a sub-directory and not the project root. It's also never been published before and Cargo.toml doesn't have an explicit include or exclude list.

I originally had Cargo.lock and target/ in the project root's .gitignore file, but copying them to the crate's directory didn't make any difference.

[ehuss]

@Michael-F-Bryan Ah, mistakenly didn't consider that the paths were relative to the repository, not the package. Fixed in #7779.

[xnuter]

The issue is still happening for me:

➜  my_project git:(initial-commit) rustc --version --verbose
rustc 1.47.0-nightly (6c8927b0c 2020-07-26)
binary: rustc
commit-hash: 6c8927b0cf80ceee19386026cf9d7fd4fd9d486f
commit-date: 2020-07-26
host: x86_64-apple-darwin
release: 1.47.0-nightly
LLVM version: 10.0

➜  my_project git:(initial-commit) cargo publish --dry-run 
.....
Caused by:
  Source directory was modified by build.rs during cargo publish. 
  Build scripts should not modify anything outside of OUT_DIR.
  Added: /Users/...../target/package/my_project-0.1.0/Cargo.lock

Switching to stable didn't help:

➜  my_project git:(initial-commit) rustc --version --verbose
rustc 1.45.2 (d3fb005a3 2020-07-31)
binary: rustc
commit-hash: d3fb005a39e62501b8b0b356166e515ae24e2e54
commit-date: 2020-07-31
host: x86_64-apple-darwin
release: 1.45.2
LLVM version: 10.0

with the same result.

Deleting Cargo.lock or removing it from .gitignore didn't help.

[ehuss]

@xnuter Source directory was modified by build.rs during cargo publish. That's a different message from this issue. Do you have a build script? It is not allowed to modify the package in any way.

[xnuter]

The build.rs script doesn't modify the directory. All it does is generating a C header file:

fn main() {
    let crate_dir = env::var("CARGO_MANIFEST_DIR")
                                 .expect("CARGO_MANIFEST_DIR variable is not set");
    let out_dir = env::var("OUT_DIR")
                                 .expect("OUT_DIR variable is not set");
    cbindgen::generate(&crate_dir)
        .unwrap()
        .write_to_file(format!("{}/my_header_file.h", out_dir));
}

The file is written into the target/release/build/.... directory.

Also it shows that the Cargo.lock file was modified. I tried to write the header file into the current dir, then the error message shows it as well.

[ehuss]

Perhaps follow up with the cbindgen project? Unfortunately cargo won't automatically include a Cargo.lock in the package unless there is a binary or example target. I'm guessing it runs cargo metadata which is generating a file within the package.