Skip to content

Enhance cargo vendor to dynamically support custom registries #15045

Open
@mireysia

Description

@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

Metadata

Metadata

Assignees

No one assigned

    Labels

    C-feature-requestCategory: proposal for a feature. Before PR, ping rust-lang/cargo if this is not `Feature accepted`Command-vendorS-needs-infoStatus: Needs more info, such as a reproduction or more background for a feature request.

    Type

    No type

    Projects

    No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions