warning: skipping duplicate package case found at ~\.cargo\git\checkouts\cargo-..

[aminya]

Problem

When using cargo install --git to install a package like cargo itself, a lot of warnings are emitted about duplicated packages. It seems that these packages are only used for the tests, and not sure if the warnings affect the final build.

warning: skipping duplicate package `cargo-list-test-fixture` found at `~\.cargo\git\checkouts\cargo-..`
...

It seems that this is caused by this commit:
e903f7d

Steps

Try to build cargo with itself:

cargo install --git https://github.com/rust-lang/cargo

Possible Solution(s)

No response

Notes

No response

Version

cargo 1.63.0-nightly (38472bc19 2022-05-31)

[weihanglo]

Thanks for the report. Those warnings won't affect any build, though flooding with warnings is definitely not good.

This situation happens when you

• build something from git, and
• the git dependency/package contains several Cargo.tomls with name conflict.

I am not sure whether this is rare or not. One simple way to solve it is reverting #10701.

[epage]

Interesting. cargo is searching recursively through cargo's git repo and finding all of the test cases we have in the repo and reporting a warning for those as we duplicate the manifest names. These should not even be given as options for install for the warning to be activated.

Besides telling the user to run cargo install --git https://github.com/rust-lang/cargo cargo I wonder if there is some way we can allow repos to exclude directories from being searched for manifests.

[epage]

We discussed this in the cargo team meeting and came up with a short term and long-term idea

Short term is to see if we can make the warning only appear when the package is publish = true

There is still the wider problem if packages being looked up that are internal. Ideas

• a breadcrumb file that says "stop recursively walking for path/git sources"
• a new manifest key that says "stop recursing and use workspace lookup rules"

[epage]

@danilhendrasr since you worked on the warnings in #10701, I thought I'd first check if you would be interested in seeing if the warning could be restricted to packages with publish = true to reduce noise from the warning.

[danilhendrasr]

Sure, I'll take a stab at it.
@rustbot claim

[epage]

Hmm, thinking about this, i suspect #10767 only gave people the tool to reduce the warnings but cargo still needs to opt-in to that tool, so going ahead and re-opening for now.

[ehuss]

Would it be possible to restrict the warning to situations where the package is actually used? That is, when doing cargo install --git or having a git dependency, only issue a warning if that package was actually part of the selected packages? I suspect that won't be easy since read_packages is pretty low-level, but I think from a user experience, that is what would be expected. Warning about unrelated packages seems to be a false-positive. Also, forcing people to use a workaround like publish=false does not seem ideal.

I would also expect this to actually be an error in the long-run. In the original issue (#10669), this leads to non-deterministic behavior. A warning just says "something's broken" and then proceeds doing something random, which doesn't seem good.

Also, the current warning does not seem to be very helpful (particularly for an end-user who may have no idea where this is coming from, or is not well-versed in cargo). There is no actionable advice given to the user, or any context as to how cargo got into this bind. I would expect in the situation with a git dependency that has a duplicate, it would say something like:

error: multiple packages named `foo` found in git repository 
https://github.com/rust-lang/example for dependency `foo` specified in `path/to/Cargo.toml`
    First instance found at `path/in/repo/Cargo.toml`
    Second instance found at `path/in/repo/other-foo/Cargo.toml`
    A git repository must only contain a single package with the name `foo`.

With similar errors for paths overrides and install --git.

(Without the ability to restrict a git repo to a specific path, the solution of being unique isn't great, but should be fine in most situations.)

[epage]

Would it be possible to restrict the warning to situations where the package is actually used? That is, when doing cargo install --git or having a git dependency, only issue a warning if that package was actually part of the selected packages? I suspect that won't be easy since read_packages is pretty low-level, but I think from a user experience, that is what would be expected. Warning about unrelated packages seems to be a false-positive. Also, forcing people to use a workaround like publish=false does not seem ideal.

The big issue with the case in question is that the user is doing

$ cargo install --git https://github.com/rust-lang/cargo

and not

$ cargo install --git https://github.com/rust-lang/cargo -p cargo

The most we can filter it down is by whether the package has an installable artifact which I think would be an additional useful thing to do.

Overall, this still leaves the big hole of cargo install installing everything in the source regardless of the source author's intent.

[ehuss]

The most we can filter it down is by whether the package has an installable artifact which I think would be an additional useful thing to do.

Overall, this still leaves the big hole of cargo install installing everything in the source regardless of the source author's intent.

I believe the former command only works if there is a single package with a binary (see here). With cargo's repo, it errors with:

error: multiple packages with binaries found: capture, cargo, cargo-credential-1password, cargo-credential-gnome-secret, cargo-credential-macos-keychain, cargo-credential-wincred, foo, mdman, semver-check. When installing a git repository, cargo will always search the entire repo for any Cargo.toml. Please specify which to install.

[DianaNites]

I'm hitting this, as an end-user, with kani as a tagged git dev dependency, every single time i build/check my project.

kani = { git = "https://github.com/model-checking/kani", tag = "kani-0.25.0", package = "kani" }

Technically speaking, the only reason I need it as a dependency is because they don't publish to crates.io and their tool adds it at runtime, but that doesnt play nice with Rust Analyzer, hence adding the dependency.

Is there any way to silence these warnings?

I'm not installing a binary so I can't just use -p kani, though i did try package = "kani" to no avail, not that I really expected that to work.

[weihanglo]

Should we reconsider redirecting error to a log file? Or at minimal, Cargo can log some parts of the error that is not meaingful to end users. We then can provide a way to retrieve a verbose error report.

The workflow might look like this,

warning: error: multiple packages with the same name found in git repository 
This may cause non-deterministic result of the compilation.
Run `cargo report errors --id 168` to see the error report.