cargo icon indicating copy to clipboard operation
cargo copied to clipboard

`cargo add` can add dependencies from crate.io registry even when using vendor or different registry

Open quagmt opened this issue 1 year ago • 2 comments

  • The same problem was already created once previously https://github.com/rust-lang/cargo/issues/10729#issuecomment-2567035063. However, it was actually not resolved or maybe there's some misunderstanding in the discussion so I create this issue to discuss this again.

Problem

When I use cargo vendor and update the .cargo/config.toml, I can not add new dependencies (which didn't exist before) to the project. The error I encounter is

❯ cargo add tracing-subscriber --features json 
error: the crate `tracing-subscriber` could not be found in registry index.

My temporary solution for this is to manually add the dependency to Cargo.toml and run cargo vendor, so that the dependency can be downloaded and added to vendor.

The problem (IMO) is that because I already changed the [source.crates-io] to vendor-sources, cargo will not look for dependencies in crate.io registry anymore and use the vendor folder instead. This is sadly quite unintuitive (and unconvenient as well) as everytime I want to add a new dependency, I need to manually adjust the Cargo.toml.

Proposed Solution

I think the best option is that cargo add should automatically look for the dependency in crates.io if it doesn't exist in vendor registry (or any registry rather than the default one), download it and update the Cargo.toml file. Then users can use cargo vendor to add the new depedency to vendor folder. It would be something like

cargo add tracing-subscriber
// download tracing-subscriber + update Cargo.toml

cargo vendor
// add tracing-subscriber to vendor folder

Notes

Here's my config.toml

[source.crates-io]
replace-with = "vendored-sources"

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

And cargo version

❯ cargo version --verbose                                                                           
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]

quagmt avatar Jan 05 '25 11:01 quagmt

Looking at #9006, it sounds like there are holes in our workflow for vendoring dependencies. We likely should take a holistic perspective in improving this so there is a common expectation for how cargo interacts with vendored sources. We especially need to keep in mind that Cargo has no special knowledge of something being vendored, just that a directory source is in use.

epage avatar Jan 06 '25 14:01 epage

It would be very nice if cargo-add worked with a vendor-based workspace.

CGMossa avatar Nov 21 '25 06:11 CGMossa