Cargo: .gitignore still overrides manifest `include`

[wagenet]

The docs on the exclude and include fields state:

If a VCS is being used for a package, the exclude field will be seeded with the VCS’ ignore settings (.gitignore for git for example).

The options are mutually exclusive: setting include will override an exclude. Note that include must be an exhaustive list of files as otherwise necessary source files may not be included.

However, .gitignore settings appear to take precedence even over files explicitly listed in include.

[wagenet]

/cc @hone @chancancode

[alexcrichton]

c @behnam (if you're interested)

[behnam]

@wagenet, cargo either filters the flies by gitignore file, or by include rules, but not both. If you share your repo/config, I can help with figuring out what the problem is for include not matching the files you want.

[wagenet]

@behnam in our experience, the .gitignore takes precedence over include rules.

The Cargo.toml is here https://github.com/tildeio/helix/blob/master/crates/libcruby-sys/Cargo.toml and the .gitignore is here: https://github.com/tildeio/helix/blob/master/crates/libcruby-sys/.gitignore.

In our tests, no lib files are included, even the ones explicitly listed unless we remove the .gitignore.

[behnam]

@wagenet, here's the code that conditions gitignore-based discovery on no include config being set:
https://github.com/rust-lang/cargo/blob/62f800fd8760faec2f4b69a464194d9b89d56983/src/cargo/sources/path.rs#L247-L252

That said, something doesn't add up from my understanding of your repo. But, unfortunately, I don't have a windows system to be able to test it myself, and the files in question are not check-in to the git.

So, any change you can share here (or somewhere private) a tree list of all your files in a built repo, so I can see the file names and paths?

Also, while there, also try cargo package --list and share the output of that as well?

[alexcrichton]

@benham one thing I vaguely remember is that things get a little odd/weird when dealing with sub-crates in a multi-crate git repo. Historically (maybe super long ago at this point) cargo had bugs related to that, and maybe that's cropping up again? (just a guess)

[hone]

@behnam We're seeing this on unix machines and the packaging doesn't happen on windows machines.

This is the output of cargo package --list.

$ cargo package --list
Cargo.toml
build.rs
ruby_info.rb
src/lib.rs

I've extracted the code from helix and was able to repro it. I've put the .lib files under the release tab, so you can download them locally. What's interesting is when I git add -f *.lib, they show up in cargo package --list.

[behnam]

Okay, I can repro, but only on stable (rust-1.19), which is basically the last release we make the recent changes.

behnam@lavin:~/code/temp/libcruby-sys (master=)$ cargo +stable package --list
Cargo.toml
build.rs
ruby_info.rb
src/lib.rs

behnam@lavin:~/code/temp/libcruby-sys (master=)$ cargo +nightly package --list
Cargo.toml
build.rs
helix-runtime-0-6-2.i386.lib
helix-runtime-0-6-2.x86_64.lib
ruby_info.rb
src/lib.rs

Since the bug is in the stable release, but not nightly/master, I can't think of a fix for you, unfortunately.
But you should be able to change one or both of .gitignore and package.exclude/package.include to achieve the setting that work.

[hone]

@behnam I can verify it works on rust-1.20 which just came out today.

[behnam]

Cool! I'm looking at my diff that touched the logic under question here, but can't think of how it was broken before.

Anyways, it's working as expected now and I suppose we can close this issue, then.

[behnam]

Ping: we can close this issue.

[alexcrichton]

Oh right, thanks!