Areas requiring agreement for stabilization of alternative registries

[cswindle]

Below are a list of current concerns that @alexcrichton raised as wanting resolution before alternative registries becomes stable:

• --registry command for publish
  • currently login, owner, publish, search, and yank have --registry as an argument, taking a registry identifier
• format of the registry name, including validation of the format
  • should we accept foo.bar.baz? Just foo-bar? What about foo-💖?
• what should be the format of the credentials file for alternative registries
  • Currently it's:

  token = ".." # crates.io token
  [custom-registry-name]
  token = ".." # custom registry token

• have we got the correct syntax for the .cargo/config file
  • Currently it's:

  [registries.custom-registry-name]
  index = "..."

• specification of index format (What is the significance of "specification" of index format/API? #4574)
• verification that the current index follows the specification (Some crates in the crates.io index have invalid json crates.io#1168)
• specification in Cargo.toml
  • Currently it's:

  [dependencies]
  foo = { version = "0.1", registry = "custom-registry-name" }

• cargo login doesn't work without a token for a custom registry, it just returns an error instead of printing a URL to visit and reading the token from a prompt
• credentials per project [Proposal] Credentials per project (local .cargo/credentials) #4645
• registry subcommand [Proposal] Subcommand to operate on custom registry info #4690

Please add to the list to include any other concerns.

[fa7ca7]

I have a few things to discuss:

• credentials per project [Proposal] Credentials per project (local .cargo/credentials) #4645
• registry subcommand [Proposal] Subcommand to operate on custom registry info #4690

What do you think?

[withoutboats]

format of the registry name, including validation of the format

Seems like there's no reason to put on it any more restrictions than what toml does, right? If your name is silly, you might need to quote & escape it in some places but toml supports arbitrary unicode strings both as table names and keys, afaik.

it just returns an error instead of printing a URL to visit and reading the token from a prompt

Does this mean it needs to accept a --registry argument like publish/yank? Probably other commands that interact with a registry should all accept this argument?

[cswindle]

Does this mean it needs to accept a --registry argument like publish/yank? Probably other commands that interact with a registry should all accept this argument?

As implemented in #4680, I have added support for cargo login to store the token in the credentials file, but only if it is provided, if not it returns an error. When you want to publish to an alternate registry you then must provide --registry <reg> as an argument. I have also added the option --registry to all commands that interact with the registry.

[alexcrichton]

@withoutboats

Seems like there's no reason to put on it any more restrictions than what toml does, right?

Perhaps, yeah, but Cargo often has things show up in weird places. For example you can specify configuration through an environment variable, and I don't actually know what that would do if you tried to specify a registry with a + in the name, for example, in an env var. These things also show up on the filesystem from time to time, which can have odd restrictions as well.

I was basically thinking that we could stick to a conservative set of names and then expand it later if we wanted.

Probably other commands that interact with a registry should all accept this argument?

Ah sorry what I meant is that if you type cargo login today it says "go visit https://crates.io/me and paste the token here". That exact same UI isn't available with cargo login --registry foo because we don't actually know for a custom registry where a token would come from. For example the index of the registry would need to provide the url https://crates.io at least (perhaps). I'm not sure we actually want to solve this though.

[carols10cents]

Before stabilization, I would like to see the index specification in cargo's docs rather than in the text of RFC 2141, so that it can be more easily discovered and corrected/modified.

[est31]

@carols10cents having a "living" document one can point to is a great idea. The RFC should mention it so that readers don't mistake the RFC for such a living document.

[sfackler]

The credentials file format has been changed to be a subset of .cargo/config in #4839. The example in this issue now looks like

[registry]
token = ".." # crates.io token
[registries.custom-registry-name]
token = ".." # custom registry token

[sfackler]

Registry names are also now a purely local concern, so I don't think we necessarily need to put any restrictions on what they look like.

[stale]

As there hasn't been any activity here in over 6 months I've marked this as stale and if no further activity happens for 7 days I will close it.

I'm a bot so this may be in error! If this issue should remain open, could someone (the author, a team member, or any interested party) please comment to that effect?

The team would be especially grateful if such a comment included details such as:

• Is this still relevant?
• If so, what is blocking it?
• Is it known what could be done to help move this forward?

Thank you for contributing!

If you're reading this comment from the distant future, fear not if this was closed automatically. If you believe it's still an issue please leave a comment and a team member can reopen this issue. Opening a new issue is also acceptable!

[carols10cents]

This is still relevant because none of the alternative registry stuff has been stabilized yet and we'd like it to be, presumably. There's a decent list of TODO items in the description of this issue and the comments; some of them definitely haven't been completed yet. To move this forward, folks could investigate and see if the tasks in this issue have been completed yet and note as such, and if they haven't been completed, work on them or ask for help in working on them.