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

[quagmt]

• The same problem was already created once previously When using a vendored directory, cargo add fuzzy searching replaces anything outside the directory with a package inside the directory #10729 (comment). 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]

[epage]

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.