Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

cargo new generates gitignore file that ignores non-root Cargo.locks, causing errors with cargo vendor #10370

Closed
ashpil opened this issue Feb 8, 2022 · 2 comments · Fixed by #10379
Labels
C-bug Category: bug

Comments

@ashpil
Copy link

ashpil commented Feb 8, 2022

The default gigignore template generates a line with Cargo.lock rather than /Cargo.lock, causing necessary Cargo.locks in non-root directories to be ignored.

This becomes an issue if one uses cargo vendor to vendor deps - as the gitignore file ignores the dependencies' Cargo.locks, which one is required to have to build without error.

@ashpil ashpil added the C-bug Category: bug label Feb 8, 2022
@ashpil ashpil changed the title cargo new generates gitignore file that ignores non-root Cargo.lock cargo new generates gitignore file that ignores non-root Cargo.lock, causing errors with cargo vendor Feb 8, 2022
@ashpil ashpil changed the title cargo new generates gitignore file that ignores non-root Cargo.lock, causing errors with cargo vendor cargo new generates gitignore file that ignores non-root Cargo.locks, causing errors with cargo vendor Feb 8, 2022
@weihanglo
Copy link
Member

weihanglo commented Feb 8, 2022

I've traced down the issue:

  1. The original implementation did ignore root /Cargo.lock. Ignore Cargo.lock for libs in cargo-new #321
  2. Someday one wanted to support both gitignore and hgingore's syntax and removed the leading slash. new: use .{git,hg}ignore syntax that's also understood by Mercurial #1247
  3. Later, one found that we should not ignore target other than under root directory and added /target back. Ignore only root target directory #4099
  4. It turns out that the syntax is not compatible between gitignore and hgignore. Therefore, one started to use hgignore special syntax to handle Cargo.lock. new: fix hgignore for real #4342

In terms of vendoring, personally I believe this should be fixed, especially when cargo start supporting artifact dependencies. Though checking out Cargo.lock into version control system for lib target is not recommended.

@Eh2406
Copy link
Contributor

Eh2406 commented Feb 8, 2022

With that explanation I am +1 on fixing this. Thanks @weihanglo for the writeup!

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
C-bug Category: bug
Projects
None yet
Development

Successfully merging a pull request may close this issue.

3 participants