The cargo information UI design

[Rustin170506]

In the workspace:

/	Conent	Why
serde@1.0.190	name and version	The basic information.
MIT OR Apache-2.0	license	When choosing a package, it is crucial to consider the license.
deps: 3	How many dependencies?	If you decide to use this package, it will display the number of dependencies that will be added.
versions: 276	How many releases?	The number of versions to some extent reflects the maturity of a library.
edition: 2018	The edition number	It indicates that the package might not use the latest edition.
rust: 1.31	The MSRV	When choosing a package, it is crucial to make sure it can work with your MSRV
keywords: #serde #serialization #no_std	The keywords	It's more like a category, which you can use to search for relevant alternatives.
A generic serialization/deserialization framework	description	The basic information
Homepage: https://serde.rs Repository: https://github.com/serde-rs/serde Documentation: https://docs.rs/serde	some links	Use these links can find more docs and information
lib: serde	The type of this package	The basic information
dependencies:	All dependencies	It indicates what it depends on.
dev-dependencies:	All dev dependencies	It indicates what it depends on.
features:	How many features? cyan color for the default feature. yellow for features enabled by the default feature.	It helps for enabling features.
authors:	The author list.	It is deprecated, so I'm not sure if we need to show it. It probably indicates the maintainers of this project.
note:	Suggest the cargo tree command. Because we pick this version from the lock file.	Help users understand why we have it.

Another one:

Out of the workspace:

[Rustin170506]

cc: @epage @weihanglo @Muscraft

[epage]

For reference, see rust-lang/cargo#948

[epage]

cargo-info shows

• download count (popularity)
• last updated

[epage]

rust-lang/cargo#10681 requests a way to see what features are explicitly enabled. We could do this for at least the default resolve. cargo tree -e features would show more.

[epage]

Looking at the prior art, I didn't see much of interest except maybe from poetry for the formatting. We should at least use bullet lists / indentation more. I also like explicit field names for things.

[epage]

Created #20

[epage]

deps: 3

imo this is a poor metric to go by that would lead to bad behavior within the ecosystem.

I also assume this is only direct dependencies unless we resolve an instance of its dependency graph?

[weihanglo]

Agree on this. This might not be a good metrics for high-quality crates.

[Rustin170506]

would lead to bad behavior within the ecosystem.

Could you explain it a little bit?

[epage]

Sometimes I've seen package authors highlight that they are a low or zero dependency package, as if that was a good thing.

The number of dependencies is meaningless on its own. Its a poor proxy for other metrics like

• Build times
• Binary size
• Number of trusted publishers

When number of dependencies becomes the focus, instead of the above, people will do things like

• Leave out glaring features
• Hand write their own unsafe code rather than reusing a widely used, well tested package

[epage]

Resolved in #18

[epage]

versions: 276

The number of versions to some extent reflects the maturity of a library.

That doesn't tell much about maturity but release cadence / churn.

imo the more interesting value (within a workspace) is what the latest version semver compatible version and latest incompatible. That both tells about the potential to upgrade and gives hints about what other versions you might ask cargo info to show.

[epage]

Resolved in #18

[epage]

edition: 2018

The edition a package uses isn't really relevant to the user. More likely it indicates the MSRV.

Maybe show this if the MSRV isn't set?

[Rustin170506]

Sounds good!

[epage]

Resolved in #18

[epage]

some links

Note: if the registry is crates.io, we likely should assume that a docs.rs page is present. crates.io will actually query crates.io and show the link automatically if the page is present. We can likely do a lower tech version.

[epage]

Resolved in #18

[epage]

All dev dependencies

These are unlikely to be relevant to the caller. vbuild dependencies might be though.

[epage]

Resolved in #18

[epage]

The author list.

As you mentioned, its deprecated.

If we can query who the registry owners are, we might want to show that.

[epage]

Created #21

[epage]

All dependencies

What should we show for non-registry dependencies?

Any other dependency information we should show?

[epage]

Created

• How should we handle the difference in dependency name vs package name? #24
• What dependency fields might be relevant to indicate? #23
• How to handle non-registry dependencies? #22

[weihanglo]

slightly off-topic but you can also add hyperlink support. See rust-lang/cargo#12888.

[epage]

Maybe I'm spoiled but most URLs will be made into hyperlinks already, I think.

So the question is what non-URL content could we make into URLs. For example, for each crates.io dependency, we could link you to crates.io or docs.rs.

[weihanglo]

That is even more awesome!

[weihanglo]

For dependencies section,

humantime: ^2.1.0
snapbox: ^0.4.13

• Do we want this part more align to how TOML looks like? It makes easier for people to copy-paste.
• Should we show ^ caret by default? I know crates.io shows that, but it's not necessary in Cargo.toml hence....

[epage]

#18 switched to name@req

I opened #25 for not showing ^

[epage]

Suggest the cargo tree command. Because we pick this version from the lock file.

I feel like the note could be simplified.

note: run `...` to see how you depend on this package

[epage]

Fixed in #18

[epage]

How many features? cyan color for the default feature. yellow for features enabled by the default feature.

Should features be a flat list or a tree? I had originally assumed a tree but seeing the flat list, I'm not sure which is better.

[epage]

A hybrid: We list out the features as a tree but have roots for every explicitly activated feature. We then list the deactivated features as a tree. Whichever list default shows up in, its first.

This makes explicit activations clear while visually showing the relationships.

Note that this assumes default might not be activated.

Two approaches:

• run feature resolver and identify what is activated (won't know explicit or not)
• parse the parent manifest and use its normal dependency entry, ignoring features and dev-dependencies.

[epage]

Created #26