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

Tracking Issue for Packages as (optional) namespaces #8292

Open
epage opened this issue Mar 12, 2024 · 5 comments
Open

Tracking Issue for Packages as (optional) namespaces #8292

epage opened this issue Mar 12, 2024 · 5 comments
Labels
C-enhancement ✨ Category: Adding new behavior or a change to the way an existing feature works C-tracking-issue Category: A tracking issue for an RFC, an unstable feature, or an issue made of many parts

Comments

@epage
Copy link

epage commented Mar 12, 2024

RFC: #3243

Allow a parent package to open its API namespace for other packages to participate

Implementation:

  • Allow one :: in the middle of package names
@epage
Copy link
Author

epage commented Mar 12, 2024

Some ideas on the UX

  • Make the parent in parent::child a link to the parent package
  • Have the parent package list all parent::child packages

One UX problem I can think of for listing all child packages is not all are created equal. liquid is a good example of where I can use this feature but I have liquid-<child> packages that are deprecated. In this scenario, they will all be shown equally. In rust-lang/cargo#2608 I bring up the idea of a user and Project editable database. We could collapse or outright hide deprecated packages if we had a way to track that.

See also

@Turbo87 Turbo87 added C-enhancement ✨ Category: Adding new behavior or a change to the way an existing feature works C-tracking-issue Category: A tracking issue for an RFC, an unstable feature, or an issue made of many parts labels Mar 12, 2024
@jsha
Copy link
Contributor

jsha commented Mar 12, 2024

FWIW, what we do in rustdoc is to be explicit: if an item is deprecated, we don't try to hide it. We include it, and mark it deprecated. I think this is also the right choice for cargo. People will find the names of deprecated packages in outdated documentation, recorded talks and so on. So the quickest way for them to learn the most up-to-date information is to see those packages listed and marked as deprecated.

If it turns out there are namespaces that have so many deprecated packages that it becomes hard to find the non-deprecated ones, it could make sense to have two sections: "Packages in this namespace" and "Deprecated packages in this namespace."

@epage
Copy link
Author

epage commented Mar 15, 2024

How precisely should this be represented in the index trie?
How we should name the .crate file / download URL

Looking through the RFC for all relevant comments on these

General requirements is that the index trie and .crate names need to be cross-platform

  • : is disallowed on Windows
  • alphanumeric, .+- are generally the characters supported by distributions wrapping .crate files
    • for go (mapping URL to distribution package), they replace reserved characters with - but migrating from packages using - to :: could cause conflicts
    • for php (with /), map to -
    • for perl (with ::), map to -

imo what cargo should use should be unambigious. This means we shouldn't map to -. To support distributions, that leaves +. Thats fairly restrictive if we ever want to support anything else, like registry namespacing (and not just API namespacing). I somewhat lean towards percent encoding of package names.

@drmason13
Copy link

Would it be possible to use -- instead of just - to replace ::?

Even if -- (or __) is allowed in crate names today, it's at least uncommon.

@epage
Copy link
Author

epage commented Jul 8, 2024

@drmason13 my proposal was to not use - and I'm not seeing any counter proposals here. We might choose to use that internally in Cargo but that is relevant for the cargo tracking issue.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
C-enhancement ✨ Category: Adding new behavior or a change to the way an existing feature works C-tracking-issue Category: A tracking issue for an RFC, an unstable feature, or an issue made of many parts
Projects
None yet
Development

No branches or pull requests

4 participants