cargo vendor can't handle duplicates.

[YellowOnion]

Problem

Caused by:
  found duplicate version of package `xi-rope v0.3.0` vendored from two sources:

        source 1: registry `crates-io`
        source 2: https://github.com/lapce/xi-editor#5578c725

Steps

No response

Possible Solution(s)

reimplement --no-merge-sources from cargo-vendor

Notes

Makes building packages on NixOS a pain to maintain:
NixOS/nixpkgs#30742

Version

No response

[Eh2406]

What were you doing when you got this error? How did you have things set up?
Can you construct a minimum complete and reproducible example for us too get the same error, if not why not?

[weihanglo]

This repo terminal-discord/weechat-discord is reproducible.

And this is a reproducible test case:

    registry::alt_init();
    let p = project()
        .file(
            "Cargo.toml",
            r#"
                [project]
                name = "foo"
                version = "0.0.1"
                authors = []


                [dependencies]
                bar = "0.0.1"

                [dependencies.foo]
                package = "bar"
                version = "0.0.1"
                registry = "alternative"
            "#,
        )
        .file("src/main.rs", "fn main() {}")
        .build();

    Package::new("bar", "0.0.1").publish();
    Package::new("bar", "0.0.1").alternative(true).publish();

    p.cargo("build").run();
    p.cargo("vendor --respect-source-config")
        .with_stderr(
            "\
[ERROR] failed to sync

Caused by:
  found duplicate version of package `bar v0.0.1` vendored from two sources:

  <tab>source 1: registry `alternative`
  <tab>source 2: registry `crates-io`
",
        )
        .with_status(101)
        .run()

There is also an existing test case for the issue: vendor::git_duplicate.

[weihanglo]

Unfortunately, cargo-vendor vendor --no-merge-sources is no longer a fallback. It can't recognize packages with either 2021 edition or lockfile v2/v3.

When running under a project with 2018 edition and lockfile v1, cargo-vendor vendor got

thread 'main' panicked at 'attempted to zero-initialize type `sized_chunks::sized_chunk::Chunk<im_rc::ord::set::Value<(core::resolver::types::DepsFrame, u32)>>`, which is invalid', /Users/weihanglo/.cargo/registry/src/github.com-1ecc6299db9ec823/sized-chunks-0.1.3/src/sized_chunk.rs:140:21
note: run with `RUST_BACKTRACE=1` environment variable to display a backtrace

Version I used to compile cargo-vendor: 1.58.0

cargo 1.58.0 (7f08ace4f 2021-11-24)
release: 1.58.0
commit-hash: 7f08ace4f1305de7f3b1b0e2f765911957226bd4
commit-date: 2021-11-24
host: x86_64-apple-darwin
libgit2: 1.3.0 (sys:0.13.23 vendored)
libcurl: 7.77.0 (sys:0.4.51+curl-7.80.0 system ssl:(SecureTransport) LibreSSL/2.8.3)
os: Mac OS 12.2.0 [64-bit]

There are two options to resolve this issue:

1. Update cargo-vendor to make it work on the latest stable version.
2. Re-implement missing flag --no-merge-sources as aforementioned.

Since #6869 concluded that we might add those missing flags back according to user feedback. I guess it's the time?

[YellowOnion]

Something else I noticed is that I can't seem to patch the .lock file to avoid this issue.

I was trying to build this package here: https://github.com/lapce/lapce

[btwiuse]

I'm also having this issue running cargo vendor on the https://github.com/gear-tech/gear repository:

$ cargo vendor cargo/vendor
error: failed to sync

Caused by:
  found duplicate version of package `sp-application-crypto v6.0.0` vendored from two sources:

        source 1: registry `crates-io`
        source 2: https://github.com/gear-tech/substrate.git?branch=gear-stable#584706a5

[bvisness]

I ran into this yesterday when trying to use my own fork of a library for testing. Judging by the error messages here, that seems to be the typical case.

While I think there may not be much legitimate use for the old --no-merge-sources, the current error message does not help you understand where the duplicates come from. It seems that they typically come from monorepos where multiple cargo packages are found under the same git ref. For example, my project uses both wast and wasm-smith from wasm-tools, both of which share the common dependency wasm-encoder (also in wasm-tools). I switched wast to my fork, but not wasm-smith, leading to duplicate copies of wasm-encoder being found.

I would suggest changing the error message to show which packages are requesting the duplicate package - and if the "please use my fork" case is in fact the typical case, perhaps the message could be tailored to that as well.