Skip to content

Config-independent way of specifying alternative registry in Cargo.toml #14500

Closed
@kornelski

Description

@kornelski

Problem

Cargo allows pulling dependencies from alternative registries by specifying registry = "name" in deps' details in Cargo.toml.

However, the registry name itself is not sufficient to identify the registry to use. It is an arbitrary nickname given in .cargo/config.toml (or even its substitute like an env var). The flexibility of this level of indirection is generally very useful during development, but it also means that the Cargo.toml information is not fully self-contained, and its real meaning depends on the environment.

This becomes more of an issue when publishing crates to a registry. The Publish API contains a JSON blob that translates the registry nicknames into proper absolute URL. But the JSON blob in the Publish API is separate from Cargo.toml, and to protect against mischievous clients, a registry server should be verifying data directly from Cargo.toml. Lack of registry URLs in the Cargo.toml is the only reason to keep the otherwise redundant JSON blob.

Proposed Solution

Cargo already rewrites Cargo.toml when publishing. If the manifest registry key was extended to allow full URLs, then Cargo could make the manifest unambiguous and self-contained during publishing.

The registry field in the JSON blob treats null value as "the registry I'm uploading to". This is very useful for the registries, since recognizing registry's own external name can be tricky (if the server is behind a proxy). This would need a special-case value in Cargo.toml too, different from absence of the registry key to avoid ambiguity with crates-io (maybe registry = "self").

Another option would be to add a mapping table to Cargo.toml, such as [registries] name = "url".

Notes

No response

Metadata

Metadata

Assignees

No one assigned

    Labels

    A-configurationArea: cargo config files and env varsA-interacts-with-crates.ioArea: interaction with registriesA-manifestArea: Cargo.toml issuesC-feature-requestCategory: proposal for a feature. Before PR, ping rust-lang/cargo if this is not `Feature accepted`Command-packageCommand-publishS-needs-team-inputStatus: Needs input from team on whether/how to proceed.

    Type

    No type

    Projects

    No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions