Support specifying API location everywhere rather than requiring specifying index location

[carols10cents]

@alexcrichton has expressed interest in this in places like this comment and I agree:

Ok but to be clear we don't even know what the "url of a registry" is today. The url we currently use in lots of places, the index, seems clearly inferior to the actual url like "https://crates.io".

Basically I don't think we should have to specify the location of an index anywhere ever, including within cargo's code, we should only ever have to specify the URL of the API server and that API should know where to find its index.

[fa7ca7]

I can't understand. This issue supposes to change index->host. #4209 changes host->index in publish subcommand. Could please someone explain why it has been merged?

[fa7ca7]

bin/search has the same mess with host/index as bin/publish.

[carols10cents]

I can't understand. This issue supposes to change index->host. #4209 changes host->index in publish subcommand. Could please someone explain why it has been merged?

#4209 changes the name of the argument; previously the argument was named host but needed the location of an index to work at all.

This issue is to actually take a host instead of an index location, everywhere, and the functionality of cargo and crates.io will need to be changed in order to close this issue.

Does that clear it up?

Please file a new issue for bin/search, thanks!

[fa7ca7]

Ah got it! Thank you for clarification.
Filed an issue #4219.

[ashleygwilliams]

notes from chatting with @carols10cents:

• needs to be done in a backwards compatible way
• need to figure out the set of all things this touches
• required for supporting multiple registries
• host appears to have been (semi?)deprecated for index, so we need to wait a cycle to repurpose host for this (hence marking as scheduled change)

[bbatha]

I just wanted to voice my concern about this proposed change. For multiple repository hosting solutions like nexus and artifactory it needs to be possible to specify a path as well. For instance, artifactory hosts npm repos at https://host.company.com/api/npm/private so you can host multiple repos for the same package manager, e.g. https://host.company.com/api/npm/private2 or multiple repo types https://host.company.com/api/cargo/internal. Specifying just the host should have a good default but it should be overridable.

[withoutboats]

So I think there are two issues here which are a bit entangled:

First, it seems like a bad UX to mention https://github.com/rust-lang/crates.io-index in the user facing interface of cargo. We do this all the time (every time we update it), and in my opinion we really should instead be saying something like crates.io in that instance. As we expand support for alt registries, the same applies there I think. This seems like an unambiguous win.

Second, @carols10cents says this:

we should only ever have to specify the URL of the API server and that API should know where to find its index.

(Note that @bbatha's response is IMO a misunderstanding: while this discussion has used URL and host interchangeably, we would definitely support arbitrary URLs and you could serve multiple registries under the same domain name.)

I don't have a formed opinion about whether the API server or the index should be the "hypermedia root" of a registry's API, but today it is the case that the root is the index. The index has a config.json file in it that specifies the URL of both the API server (which is expected to implement an API like crates.io) and the crate server (which is expected to serve tarballs of crates under certain paths).

How would the migration work to a new system in which the API server reports the URL of the index instead of the other way around? What are the advantages of moving to a system that works this way? Do they outweigh the cost of that migration?

Not saying we shouldn't do this, just trying to suss out the trade off between a possibly better system and performing the migration.

[alexcrichton]

This seems like an unambiguous win.

Agreed!

[carols10cents]

Is this moot now that we have --registry and the registries configuration where the index URL is specified? That is, should we just close this?

[withoutboats]

There's still the stuff about crates.io saying the github index instead of something more user friendly, unless that was fixed? But maybe this should be closed and a new, narrower issue should be opened?

[kellda]

Any update on --host status ?

cargo/src/cargo/util/command_prelude.rs

Lines 556 to 559 in bf1a26d

	fn index(&self, config: &Config) -> CargoResult<Option<String>> {
	// TODO: deprecated. Remove once it has been decided `--host` can be removed
	// We may instead want to repurpose the host flag, as mentioned in issue
	// rust-lang/cargo#4208.