Rust: Tracking issue for RFC 2141: Add support to Cargo for alternative registries

[aturon]

This is a tracking issue for the RFC "Add support to Cargo for alternative registries" (rust-lang/rfcs#2141).

Steps:

• [x] Implement the registries key in .cargo/config and Cargo.toml - https://github.com/rust-lang/cargo/pull/4506
• [x] Support login tokens for multiple registries - https://github.com/rust-lang/cargo/pull/4680
• [ ] [Add a command to generate registry index data](https://github.com/rust-lang/cargo/issues/4497)
• [ ] Allow renaming crates in the dependencies section - https://github.com/rust-lang/cargo/issues/1311 (also necessary for RFC 2126: Clarify and streamline paths and visibility)
• [x] [path and registry shouldn't be mutually exclusive in dependency configurations](https://github.com/rust-lang/cargo/issues/4843) - https://github.com/rust-lang/cargo/pull/4844
• [ ] Track which commands a registry supports in its config.json - https://github.com/rust-lang/cargo/pull/4747
• [x] Make .cargo/credentials a subset of .cargo/config - https://github.com/rust-lang/cargo/pull/4839
• [ ] [What is the significance of "specification" of index format/API?](https://github.com/rust-lang/cargo/issues/4574)
• [ ] [Areas requiring agreement for stabilization of alternative registries](https://github.com/rust-lang/cargo/issues/4688)
• [ ] Adjust documentation (see instructions on forge)
• [ ] Stabilization PR (see instructions on forge)

Unresolved questions:

• Are the names of everything what we want?

  • cargo generate-index-metadata?
  • registry = my-registry?
  • publish-registries = []?

• What kinds of authentication parameters do we need to support in .cargo/credentials?

[matklad]

I think PR is already in flight: https://github.com/rust-lang/cargo/pull/4506

[cswindle]

I have PR for adding the parts in the RFC about changes to publish: rust-lang/cargo#4568

[est31]

I've encountered some issues with the official crates.io index. It appears to be non-conformant to the spec: https://github.com/rust-lang/crates.io/issues/1168

[ninrod]

Hi, this issue seems to target enterprise usage. This means artifactory support, which is really the standard in enterprise, right? Right now I want to use rust in my company and cannot because of that.

Would it be useful to add a bullet like: "works in artifactory"?

[wycats]

@ninrod I think we'd want to get some eyeballs and feedback from Artifactory, but I don't necessarily think we need to wait to stabilize until they actually implement.

[wycats]

@est31 I commented on rust-lang/crates.io#1168

[stuhood]

@ninrod : Bumps on https://www.jfrog.com/jira/browse/RTFACT-13469 would be appreciated.

[ccojocar]

What's the current state of this issue? Has anyone managed to use Nexus for cache purposes? The dependencies installation is kind of slow, especially on an ephemeral build system. Thanks

cc @rawlingsj

[aaronsky]

Very interested in Artifactory support for Cargo. I want to start pushing Rust more at my company but if I can't use Artifactory rather than crates.io, distribution is made much more difficult.

[gilescope]

How are we doing? Is there something I can try out in my company? And also do we need to team up and create an artifactory plugin?

Really this should be tagged Rust 2018 edition (if not earlier), because if we can't use Rust at work what's the point?

[aaronsky]

Speaking personally, I don't know what's involved in creating an Artifactory plugin for something of this potential scale. I have been trying to find some information or examples on how folks in other communities have approached bootstrapping rudimentary Artifactory support for their ecosystem. I have also been ramping up on Cargo and how to implement the missing pieces outlined in the tracking issue.

I would love to help more seriously with this effort as it is a deciding factor on whether we can use Rust at my organization.

[ebkalderon]

Not having support for alternative registries in Cargo is a massive pain. Working with private Git dependencies gets rather difficult at scale, and having private registries would make our lives so much easier.

[cswindle]

@aaronsky, I did some work creating a server which is able to act as a registry https://crates.io/crates/caesium, this allows having different plugins to interface to different storage backends, one of which is artifactory. Please note that it does not offer a web frontend, but it does give the ability to upload crates to artifactory and update the git backend. This was mainly developed for testing some of the alternative registries code rather than actually running a production system.

[boskiv]

Does anyone used https://crates.io/crates/caesium?
Is there some instruction how to publish crate there ?

[boskiv]

Guys, Is there any updates or milestones for this issue ? May be there is some workarounds ? From DevOps perspective it's a very complicated today to manage private dependencies.

[ahmedcharles]

The RFC doesn't specify which characters are valid in fields in the registry index data. Is it possible to clarify that? E.g. Is a crate name allowed to contain '@', '#' or '$'.

[sharksforarms]

Any updates on this?

[ehuss]

My goal is to have it stabilized in 1.34 (releases Apr 11). No promises, but that's what I'm working towards. If anyone has any final feedback on the implementation, now would be a good time.

[ehuss]

Proposal to stabilize has been posted at https://github.com/rust-lang/cargo/issues/6589.

[mitchdenny]

Hi folks - I'm from the Azure Artifacts team. We support private package registries for a bunch of protocols including Maven, PyPi, NuGet and NPM. Some folks have started asking us about support crates. We are interested in learning more about the way you are approaching extensibility.

[alexcrichton]

@mitchdenny hello! You'll probably want to take a look at https://github.com/rust-lang/cargo/issues/6589 which is being proposed for stabilization. If there's something though that's missing, please let us know!