Enhance cargo vendor to dynamically support custom registries

[mireysia]

Problem

In airgapped or highly secured env, direct access to crates.io is not feasible. Instead, users rely on sanitized, mirrored registries for deps resolutions. Currently, cargo vendor can target a custom registry using the --respect-source-config flag, but this requires defining a static .cargo/config.toml file with the desired source configurations.

This approach is inflexible and cumbersome, especially for dynamic or ephemeral builds where registry configurations may vary. There is no straightforward way to dynamically specify a custom registry or exclude crates.io without modifying project files

Proposed Solution

• Add a flag to cargo vendor to dynamically specify a custom registry (--registry <registry-name>)
• Introduce an option to exclude crates.io from dependency resolution entirely
• Allow these flags to override .cargo/config.toml temporarily, providing more flexibility for users in airgapped or dynamic environments

Notes

• This enhancement would simplify workflows for teams relying on mirrored or internal registries without requiring local file modifications
• It ensures reproducibility and compliance in environments where crates.io cannot be accessed
• The proposed solution remains compatible with existing --respect-source-config behavior while offering more flexibility

[Eh2406]

Anything that can be set in a .cargo/config.toml can also be set using environment variables.

[weihanglo]

Defining a source replacement for crates-io is not trivial at this moment. You'll need to have two tables:

[source.crates-io]
replaced-with = "mirror"

[source.mirror]
registry = "https://example.com/path/to/index"

However, as Eh2406 has mentioned, this could be done in environment varilable, and also via the --config cli flag. For example, using the crates.io mirror from Tsinghua University:

cargo vendor --respect-source-config \
  --config 'source.crates-io.replace-with="mirror"' \
  --config 'source.mirror.registry="sparse+https://mirrors.tuna.tsinghua.edu.cn/crates.io-index/"'

If you have a separate config.toml containing those setup, you could also load it via --config when needed:

cargo vendor --respect-source-config --config tuna.mirror.config.toml

Introduce an option to exclude crates.io from dependency resolution entirely

You could put an undefined registry name in .cargo/config.toml. If no valid mirror is provided,
Cargo always bails (of course, in cargo vendor you need to pass --respect-source-config).

[source.crates-io]
replace-with = 'undefined'

$ cargo b
error: failed to get `serde_json` as a dependency of package `foo v0.1.0 (/projects/foo)`

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

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

Caused by:
  could not find a configured source with the name `undefined` when attempting to lookup `crates-io` (configuration in `/projects/foo/.cargo/config.toml`)

• Allow these flags to override .cargo/config.toml temporarily, providing more flexibility for users in airgapped or dynamic environments

Likewise, you can override it via the --config cli.

[weihanglo]

The above approaches to me seem very versatile. Let us know if you have any special workflow that none of them fits your requirement.