Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

pkgid spec confusion #7725

Closed
ehuss opened this issue Dec 19, 2019 · 4 comments
Closed

pkgid spec confusion #7725

ehuss opened this issue Dec 19, 2019 · 4 comments
Labels
A-documenting-cargo-itself Area: Cargo's documentation C-bug Category: bug Command-pkgid S-propose-close Status: A team member has nominated this for closing, pending further input from the team

Comments

@ehuss
Copy link
Contributor

ehuss commented Dec 19, 2019

The documentation for the package id spec (https://doc.rust-lang.org/1.40.0/cargo/reference/pkgid-spec.html) does not seem to be correct in several ways.

  • The proto is not optional. Cargo defaults to cargo:// which is not a scheme Cargo understands anywhere.
  • crates.io as a host does not work. It looks like you can only give the full path to the index, like https://github.com/rust-lang/crates.io-index#bitflags:1.2.1
  • host/name doesn't work. It looks like the matching code requires the entire scheme/host/path to match.

The question is, what should we do? Should we just remove all the things that don't work from the documentation? Or should we try to enhance the parsing/matching code to work better.

  • Should crates.io work as an alias for https://github.com/rust-lang/crates.io-index?
  • Missing proto probably shouldn't default to anything, and should probably match any proto.
  • Should host/name match host/path#name?

EDIT: #9188 and #9249 fixed the broken parts, but leaving this open to consider adding abbreviated forms.

@alexcrichton
Copy link
Member

Oh dear that didn't exactly age well...

I think though we've started using crates-io in other places such as [source.crates-io], so supporting either a full host name or the "short name" of the registry seems like a good thing to support (we don't support this today afaik).

As for the proto business I think it's fine to basically remove that and make the docs match the current implementation.

In any case, what I would propose:

  • First make the docs match the current implementation
  • Next support registry-identifier/crate-name where registry-identifier matches what we do for alternative registries.

bors added a commit that referenced this issue Mar 10, 2021
Update pkgid-spec docs.

The old docs for the pkgid spec weren't correct. Specs never supported abbreviated URLs or aliases for the index (like `crates.io`).  This tries to correct that and add a little more detail.

Part of #7725.
@epage epage added the A-documenting-cargo-itself Area: Cargo's documentation label Nov 3, 2023
@epage epage added the S-needs-design Status: Needs someone to work further on the design for the feature or fix. NOT YET accepted. label Nov 3, 2023
@epage epage added S-propose-close Status: A team member has nominated this for closing, pending further input from the team and removed S-needs-design Status: Needs someone to work further on the design for the feature or fix. NOT YET accepted. labels Dec 4, 2024
@epage
Copy link
Contributor

epage commented Dec 4, 2024

I'm proposing we close this. All that is left is considering more abbreviated forms. In the 5 years this has been open, no one has piped in about wanting some. Instead of tracking this as a speculated need, I'd recommend we wait until a user requests it.

@ehuss
Copy link
Contributor Author

ehuss commented Dec 5, 2024

Sounds good!

@ehuss ehuss closed this as completed Dec 5, 2024
@ayanwaar

This comment has been minimized.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
A-documenting-cargo-itself Area: Cargo's documentation C-bug Category: bug Command-pkgid S-propose-close Status: A team member has nominated this for closing, pending further input from the team
Projects
None yet
Development

No branches or pull requests

4 participants