`cargo add` can add dependencies from crate.io registry even when using vendor or different registry
- 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]
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.
It would be very nice if cargo-add worked with a vendor-based workspace.