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.)