Open epage opened 6 months ago
Some ideas on the UX
parent
in parent::child
a link to the parent
packageparent
package list all parent::child
packagesOne 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
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."
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.+-
are generally the characters supported by distributions wrapping .crate
files
-
but migrating from packages using -
to ::
could cause conflicts/
), map to -
::
), 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.
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.
@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.
RFC: #3243
Allow a parent package to open its API namespace for other packages to participate
Implementation:
::
in the middle of package names