path dependency on git dependency not found on monorepo with several workspaces

[DavidBM]

Problem

When a crate (LOCAL) tries to import a crate (A) from a git repository (monorepo that has several cargo workspaces), if the crate (A) has a path dependency to another crate (B) in the same monorepo but different workspace, it won't find it when building the LOCAL crate.

It will fail with an error like:

error: no matching package named `B` found
location searched: <MONOREPO LINK>
required by package `A v0.1.0 (<MONOREPO LINK>)`
    ... which satisfies git dependency `A` of package `LOCAL v0.1.0 (<LOCAL PATH TO LOCAL CRATE>)`

This is extra confusing because it seems that cargo treats the a path dependency as a git dependency in this case. So location searched is the same git link as the link of the crate A. Which makes sense, because they exist in the same repo and thus makes sense to search them in the same folder where the git repo syncs. It is just a bit confusing when reading.

The issues seems to be that cargo scans the whole monorepo to find packages (even if the root folder is not a workspace) for resolving A, but it doesn't when searching for B.

Steps

Create a repo with 2 cargo workspaces. Make a crate in each workspace (A and B).
Make A depend on B using a path definition on the Cargo.toml.

Create a local crate in your computer and add a git dependency to the crate A. See it fail to resolve B.

Possible Solution(s)

When resolving B, the same crawl explained in here: #1462 (comment) should happen, so the package can be found

Notes

This is happening using our internal gitlab instance. I assume this would happen with any remote git provider. For this case we used https links.

Version

cargo 1.83.0 (5ffbef321 2024-10-29)
release: 1.83.0
commit-hash: 5ffbef3211a8c378857905775a15c5b32a174d3b
commit-date: 2024-10-29
host: x86_64-unknown-linux-gnu
libgit2: 1.8.1 (sys:0.19.0 vendored)
libcurl: 8.9.0-DEV (sys:0.4.74+curl-8.9.0 vendored ssl:OpenSSL/1.1.1w)
ssl: OpenSSL 1.1.1w  11 Sep 2023
os: Ubuntu 24.4.0 (noble) [64-bit]

[weihanglo]

A solution to this may need to resolve every referenced workspace for path dependencies, especially when workspace inheritance is involved. This sounds like a variant and a use case of nested workspaces #5042?

[epage]

I'm confused by this because the git source doesn't really care about workspaces. This needs to be verified and root-caused as I hope this is solvabde without anything like nestwd workspaces.

[weihanglo]

@DavidBM mind setting up a minimal reproducible repo on GitHub/GitLab/wherever so we can reproduce and investigate?

[DavidBM]

I tried to build a reproducible example. But it works with public repositories in github.

It fails in our internal gitlab. I will do more research and come with another well defined issue.

Apologies for the noise.