Transitivity issues in crate renaming in private registry

help
#1

Hello,

I have a weird problem when using crate renaming in a project ("multi-bars") that is used as a dependency of a bigger one.

In multi-bars/Cargo.toml I have

bar7 = { version = "7", registry = "private", package = "bar" }

and everything works fine (I can compile and publish multi-bars, since bar v7 is available)

But in the project foo that uses multi-bars:

multi-bars = { version = "0.1.1", registry = "private" }

cargo cannot figure out the dependency tree :

$ cargo version
cargo 1.59.0 (49d8809dc 2022-02-10)

$ cargo tree
    Updating crates.io index
    Updating `private` index
error: no matching package named `bar7` found
location searched: registry `private`
required by package `multi_bars v0.1.1 (registry `private`)`
    ... which satisfies dependency `multi-bars = "^0.1.1"` of package `foo v3.1.2 (/path/to/foo)`

I don't understand why cargo can't figure out the dependency I want to use. Is there something obvious I missed ?

#2

The registry implementation you're using might not have the logic to handle renamed dependencies properly.

#3

I've checked the dependency entry in my registry, and there's definitely an error there but I'm not sure it should have an impact:

{
      "name": "bar",
      "req": ">=7.1.0, <8.0.0",
      "features": [],
      "optional": false,
      "default_features": true,
      "target": null,
      "kind": "normal",
      "registry": null,
      "package": "bar7"
    },

From looking at the Cargo book it seems the package key should be a explicit_name_in_toml key, but anyway, cargo should use the name to search for the package right ?

#4

I got it wrong, the Cargo book extract I looked at was the payload used in publish, not the expected format at rest, so there's indeed an issue in my registry. Sorry for bothering, thanks for rubberducking.

#5

This topic was automatically closed 90 days after the last reply. We invite you to open a new topic if you have further questions or comments.