Error about ambiguous package name in workspace, but there is only one with that name

1

I'm working on the feat/taffy-grid branch of my fork of iced_aw: GitHub - avsaase/iced_aw at feat/taffy-grid (don't look at the code changes, it's a WIP). When I try to run the grid example with cargo run --package grid I get the error

error: There are multiple `grid` packages in your project, and the specification `grid` is ambiguous.
Please re-run this command with `-p <spec>` where `<spec>` is one of the following:
  grid@0.1.0
  grid@0.10.0

As far as I can see there is there is no second grid package in this workspace so this error doesn't make sense to me. When I follow cargo's suggestion it also says that these packages don't exist in the workspace.

The other examples in the workspace work and on the master branch this example also works.

I tried removing the target folder and deleting the lock file but that didn't help. Did I hit some kind of cargo bug?

2

You have an example with the crate name grid of version 0.1.0. In addition you depend on taffy, which in turn depends on a crate called grid from crates.io and this one has version 0.10.0. When you do cargo run -p grid it is ambiguous if you are referring to your example or to the grid crate from crates.io.

3

I don't understand why cargo would think I want to "run" a transitive dependency. Is there a way to override this behavior?

If not, how can I run my example? When I follow the suggestion and run cargo run -p grid@0.1.0 it says

error: package(s) `grid@0.1.0` not found in workspace `~/iced_aw`
4

I'm not sure. Maybe open a cargo issue?

5

cargo run does behave differently than other commands (e.g. --workspace is not accepted even though it could sometimes make sense) so I wouldn't be surprised if there's an inconsistency bug here.

It's generally a good idea to avoid reusing package names to keep things simple and clear, though.

6

I'm not sure what you mean here. If package names within a workspace should be globally unique to avoid conflicts with (transitive) dependencies then that would be very fragile.

1 Like
7

I created a bug report here: Cargo incorrectly detects a package name conflict when a workspace package has the same name as a (transitive) dependency · Issue #12891 · rust-lang/cargo · GitHub

1 Like
8

I'm saying that it's a good idea to try to avoid identical names, not that you can guarantee that. It makes various diagnostic output easier to read, even if nothing else.

1 Like