Cannot build vendored git dependency if it inherits info from a workspace

[hunts]

Problem

If we cargo vendor our dependencies, and one of the crates in the vendor folder is inheriting package info from its Workspace, cargo build --offline would fail with errors like:

Caused by:
  error inheriting `version` from workspace root manifest's `workspace.package.version`
Caused by:
  failed to find a workspace root

Steps

1. Add a crate that is from a project using Workspace inheritance

$ tail Cargo.toml
...
[dependencies]
lib-in-workspace = { git = "ssh://git@internal-git-service/rust-project-using-workspace.git", tag = "v0.176.0" }
...

2. Vendor dependencies:

$ cargo vendor >> .cargo/config.toml

$ tail .cargo/config.toml
...
[source."ssh://git@internal-git-service/rust-project-using-workspace.git"]
git = "ssh://git@internal-git-service/rust-project-using-workspace.git"
tag = "v0.176.0"
replace-with = "vendored-sources"

[source.vendored-sources]
directory = "vendor"

$ cat Cargo.lock
...
[[package]]
name = "lib-in-workspace"
version = "0.176.0"
source = "git+ssh://git@internal-git-service/rust-project-using-workspace.git?tag=v0.176.0#7efcf95d618e9af79431e036414903fe3b4954b8"
dependencies = [
 "aho-corasick",
 "bstr",
 "cc",
 ...
]
...

3. Build app offline

$ cargo build --offline --release

error: failed to get `aho-corasick` as a dependency of package `app v0.1.0 (/home/hunts/code/app)`

Caused by:
  failed to load source for dependency `aho-corasick`

Caused by:
  Unable to update registry `crates-io`

Caused by:
  failed to update replaced source registry `crates-io`

Caused by:
  failed to parse manifest at `/home/hunts/code/app/vendor/lib-in-workspace/Cargo.toml`

Caused by:
  error inheriting `version` from workspace root manifest's `workspace.package.version`

Caused by:
  failed to find a workspace root

4. Check what's in the crate's Cargo.toml

$ head vendor/lib-in-workspace/Cargo.toml

[package]
name = "lib-in-workspace"
version.workspace = true
authors.workspace = true
description.workspace = true
edition.workspace = true
publish.workspace = true

Possible Solution(s)

I'm no familiar with the workspace design, but it feels like we need to replace the workspace variables with real values when vendor a crate, or will need to provide metadata of the workspace the crate is sourced from.

Notes

I've anonymized the package/lib names related to our internal systems, hope that won't cause inconvenience in understanding the problem.

Version

cargo 1.64.0 (387270bc7 2022-09-16)
release: 1.64.0
commit-hash: 387270bc7f446d17869c7f208207c73231d6a252
commit-date: 2022-09-16
host: x86_64-unknown-linux-gnu
libgit2: 1.4.2 (sys:0.14.2 vendored)
libcurl: 7.83.1-DEV (sys:0.4.55+curl-7.83.1 vendored ssl:OpenSSL/1.1.1q)
os: Ubuntu 22.04 (jammy) [64-bit]

[weihanglo]

Thank you for reporting this bug! @Muscraft and I had a talk, and we feel that it might take longer before a better design for this come out. So, in the meanwhile, we are seeking help for polishing the error message. Something explicitly tells user the cause is great, such like "vendoring a git dependency with inherited fields from a workspace is not supported yet".

[ipetkov]

@weihanglo just curious for my own understanding, is the limitation here that cargo vendor doesn't (yet) know how to vendor such crates, or is it a broader issue that cargo itself cannot support offline building of such crates?

I'm interested in supporting dependencies with workspace inheritance in Crane (tl;dr an alternative implementation of cargo vendor to work with Nix) and wanted to understand where/what the limitations actually are!

[weihanglo]

@ipetkov Haven't dived deep yet but I don't think this affects general cases.

So far it seems to happen only when building a vendored git dependency which inherits info from its parent workspace. I guess it's cp_sources copying the crate sources without copying the whole workspace, and then cargo realizes workspace information is not there.

This is a reproducible case in the form of cargo's own test suite if anyone is interested.

Click to see test code

#[cargo_test]
fn vendor_git_source_from_workspace_with_inheritance() {
    let git = git::new("gitworkspace", |p| {
        p.file(
            "Cargo.toml",
            r#"
                [workspace]
                member = ["foo"]

                [workspace.package]
                version = "0.1.0"
            "#,
        )
        .file(
            "bar/Cargo.toml",
            r#"
                [package]
                name = "bar"
                version.workspace = true
            "#,
        )
        .file("bar/src/lib.rs", "")
    });

    let p = project()
        .file(
            "Cargo.toml",
            &format!(
                r#"
                    [package]
                    name = "foo"
                    version = "0.1.0"

                    [dependencies]
                    bar = {{ git = '{}' }}
                "#,
                git.url(),
            ),
        )
        .file("src/lib.rs", "")
        .build();

    p.cargo("vendor --respect-source-config")
        .run();

    p.change_file(
        ".cargo/config.toml",
        &format!(r#"
            [source."{url}"]
            git = "{url}"
            replace-with = 'vendor'

            [source.vendor]
            directory = 'vendor'
        "#,
            url = git.url(),
        ),
    );
    p.cargo("build").with_stderr("").run();
}

Click to see error output

error: failed to get `bar` as a dependency of package `foo v0.1.0 (/projects/cargo/target/tmp/cit/t0/foo)`

Caused by:
  failed to load source for dependency `bar`

Caused by:
  Unable to update file:///projects/cargo/target/tmp/cit/t0/gitworkspace#02b3fb58

Caused by:
  failed to update replaced source file:///projects/cargo/target/tmp/cit/t0/gitworkspace#02b3fb58

Caused by:
  failed to parse manifest at `/projects/cargo/target/tmp/cit/t0/foo/vendor/bar/Cargo.toml`

Caused by:
  error inheriting `version` from workspace root manifest's `workspace.package.version`

Caused by:
  failed to find a workspace root
', tests/testsuite/vendor.rs:990:38

---

@hunts I edited the title a bit to reflect the issue more precisely. At this moment I can't see any case other than git dependency having this issue. If we later find it's broader than that, we can always update then.

[ipetkov]

@weihanglo can an entire workspace be copied over intact into the vendor directory? I had assumed there was a reason why cargo vendor puts each crate into its own directory (even ones coming from the same workspace)

[hunts]

Thanks, the updated title sounds good to me.

[weihanglo]

@ipetkov

Off the top of my head, there are at least two approach to solve this:

1. Fill in all field having workspace = true with the actual data when copying git dependencies
2. As you proposed, copy the whole workspace into some place in vendor directory for git dependencies to refer to.

I would say it has technical difficulties in pulling workspace into vendor directory. Firstly, a directory source at this moment is in a flat one-level layout listing all crates on the same level. By copying workspaces into vendor directory, we need to craft a special algorithm to identify the relationship between crates and workspaces. We also need to mind any name conflicts on crate names and our special folders (which I mentioned a while back here #11178 (comment)). Besides, pulling the whole workspace does contribute to size bloat. If we want to tackle it, we might need another way to slim down unnecessary members, which is also hard and might break things.

For me, I don't like the first approach, as it modifies the original Cargo.toml. However, before we figure out a better way to circumvent this, it stills sounds feasible than the latter.

[ipetkov]

For me, I don't like the first approach, as it modifies the original Cargo.toml. However, before we figure out a better way to circumvent this, it stills sounds feasible than the latter.

Definitely agree with your sentiment! It looks like cargo will normalize the Cargo.toml by copying the workspace-inherited definitions before publishing a crate. it might be that vendoring will need to take this approach as well :/