cargo vendor is not consistent about paths and symbolic links on Windows vs. other platforms

[glandium]

Problem

About paths:
when a crate contains paths for e.g. dependencies in a workspace, cargo vendor uses / on Unices and \ on Windows, changing whatever the original path was.

About symbolic links:
when a crate contains symbolic links to another file in a workspace, cargo vendor expands the content on Unices and replaces it with the path of the link target on Windows.

Steps

1. cargo new foo
2. cd foo
3. cargo add libz-rs-sys
4. cargo vendor

On Linux or Mac, you end up with a proper vendor/libz-rs-sys/LICENSE file, and vendor/libz-rs-sys/Cargo.toml has dependencies.zlib-rs.path = "../zlib-rs".
On Windows, vendor/libz-rs-sys/LICENSE literally contains ../LICENSE, and vendor/libz-rs-sys/Cargo.toml has dependencies.zlib-rs.path = "..\zlib-rs".

Possible Solution(s)

cargo vendor should be consistent, wherever it's run.

Notes

No response

Version

[weihanglo]

@glandium I had a hard time reproducing this. The repro seems to depend on a non-exact package version on crates.io. And even after I tried some recent versions, I didn't see dependencies.zlib-rs-sys.path in the manifest file. Were you using git dependencies then? If yes which commit and repo?

[glandium]

Did crates.io repackage crates? I'm pretty sure I tested with crates.io back then, and I can't reproduce myself now.

But this is reproducible with libz-rs-sys = {git="https://github.com/memorysafety/zlib-rs"}

[weihanglo]

Did crates.io repackage crates? I'm pretty sure I tested with crates.io back then, and I can't reproduce myself now.

I am not aware of that. Even it really did, cargo publish should copy LICENSE and normalize the path (there were some bugs though).

I'll go ahead and close this as a duplicate of #7051, as they are all git-dependency related. Thank you!