New lib.rs feature: maintainer dashboard

announcements
1

lib.rs will show you if there are any things that need fixing in your crates. It checks if dependencies are up to date (and it's smart about it — it recognizes how much outdated they are), and reports any issues it finds in crate's metadata. Basically, it's a validator for published crates.

You can see dashboard for your crates at https://lib.rs/~your_github_username_here/dash

Examples: 1, 2, 3.

It's designed to be used via RSS reader! Subscribe to a feed: https://lib.rs/~your_github_username_here/dash.xml and you will get notified when your crates need attention. You can delete items from the feed when you fix them or decide they don't need fixing.

37 Likes
2

There's one more toy feature: you can clone any crate's git repository by cloning its URL on lib.rs. It's not meant for any serious work (it's a read-only redirect), but if you just want to quickly have a peek at crate's source code, it's as easy as:

git clone https://lib.rs/arbitrary
6 Likes
3

I wouldn’t mind a comma, or other separator in the list of crates if there’s nothing to fix.

@steffahn's Rust crates // Lib.rs

You might also want to implement a redirect for dashes vs. underscores mismatches, in case that’s possible?

4

Some quick first-impression feedback:

  • The "add keywords" hint needs a filter against common English words, like "is". It also included words that are in the names of my crates (hyphen separated) which should probably be excluded.

  • The outdated dependency descriptions feel unclear. In particular, I found myself wondering whether they were major versions. It looks like they're all major (which is good at least for libraries).

5

  • I think the "locked dependency version" signal is too aggressive. These = dependencies are correct and 100% unproblematic for crates that are always versioned together, like a lib and its proc macro implementation. Can you avoid triggering this signal on crates that come from the same repo?

    Screenshot from 2022-01-27 10-35-33
    Screenshot from 2022-01-27 10-35-331820×338 46.4 KB


  • To my knowledge, all published versions of serde_test compile with all versions of rustc since 1.13 so I can't tell where this 1.48 estimate comes from, or what I can do to make my crate easier to identify a minimum rustc on. Is there a way to have the text clarify where this estimation comes from, such as "because it uses feature X" or "because we tried building version Y with rust Z and that failed with error W"?

    Screenshot from 2022-01-27 10-36-30
    Screenshot from 2022-01-27 10-36-301906×650 103 KB

3 Likes
6

Yes, this was my first reaction looking at my dashboard page, too.

And thank you for this great feature.

7

The outdated crates feature will certainly be useful but perhaps the message should be a little changed for crates which are pure bin.
I mean "Upgrade to the latest version to get all the fixes, and avoid causing duplicate dependencies in projects." isn't completely relevant when your crate is only an application.

5 Likes
8

The MSRV estimate is based on cargo check running in rustops/crates-build-env docker image (same as docs.rs) and parsing JSON error output from the compiler. It does look at features, and also takes into account MSRV of dependencies.

The high MSRV for serde_test could have been due to other crates enabling alloc feature in it, which causes a compile failure with the current stable compiler.

9

serde_test does not have an "alloc" feature. Are you saying crates might've been published that attempt to specify a dependency on serde_test = { version = "1", features = ["alloc"] }, and that would get identified by lib.rs as serde_test failing to build?

error: failed to select a version for `serde_test`.
    ... required by package `repro v0.0.0 (/git/repro)`
versions that meet the requirements `^1.0` are: 1.0.136

the package `repro` depends on `serde_test`, with features: `alloc` but `serde_test` does not have these features.
10

Sorry, I've confused it with serde's features.

11

I would have expected this to get the actual source code as published on crates.io which may not match the git repo.

4 Likes
12

Complaining about fixing package versions with = for 0.x versions seems weird to me when the general rule for 0.x packages seems to be "anything goes" -- in particular people often bump the minimum compiler version in 0.x.y+1 updates, so I need to use = so I know my program will compile in future.

I could understand if some packages are willing to make stronger promises in 0.x.y package versions, and could somehow make that fact public.

13

That's not because "anything goes"; it's because bumping the minimum compiler version is generally regarded as a non-breaking change when done in a reasonable manner.

1 Like
14

Unfortunately (and I imagine many rust devs don't like it) I find many users install Rust from their OSes package system, so I find I need to support the rust compiler in current Ubuntu and Debian releases.

Also, "anything goes" was a quote from the cargo docs on package behaviour below 1.0.0.

1 Like
15

That's why I said in a reasonable manner. My policy, along with many other large crates, is to support compilers released in the last six months.

16

Unfortunately, in the Rust/Cargo ecosystem, 0.x version doesn't mean much, and Cargo's rules for 0.x are different from semver rules for 0.x. There are major widely-used crates that are on 0.x ( libc, time, log, futures). Plenty of 0.x crates are de-facto mature and stable. libc probably won't ever have a 1.0.0 release, because it's so stable and widely used it's not worth the churn.

All crates tend to bump MSRV in minor releases. It's not limited to "experimental" ones. In the ecosystem there's simply no agreement about this issue, and MSRV-breaking wins just because of the network effect, e.g. if you have 100 transitive dependencies, and 99 crates agree to bump MSRV only on major version, but 1 doesn't agree, then your project is still broken. IMHO this situation is hopeless. It's not even worth trying to preserve MSRV beyond last 3 Rust releases.

I know packaged Rust is problematic. Debian's Rust is the worst one. It practically doesn't work with anything from crates-io. It is and will remain useless until either Rust or Debian change their release policies, and they won't, because each project has a good reason to be this way. I don't see any way around this other than to keep warning users to never ever use Debian's Rust. At least after 1.56 (in Debian in ~2023), Debian users will get a clear error messages about their outdated Rust rather than odd compilation breaks or false "needs nightly" errors.

It's not worth trying to fix these MSRV breaks by locking dependency versions, because that causes even bigger issue for all Rust users: conflicts. Cargo allows only a single semver-major version per dependency. If you use =1.0.1 and someone else uses =1.0.2, the project won't build at all. Even if you try to be flexible and use >=1.0.0. <=1.0.2, then any crate with 1.0.3 will break the project too, and not just for old Rust versions, but for everyone. We've been there when some crates had broken releases. We've been there with zeroize. We've been there with bincode vs byteorder MSRV fight. You can still "pin" dependencies in your private projects and binary crates, but please don't do that in libraries used by others. It only ends up causing even more breakage.

I think currently the best chance of supporting older Rust versions is -Z minimal-versions which could work if people stop putting imprecise dependency versions in their crates. If you specify serde = "1.0", then -Z minimal-versions will roll it back by 160 releases, and 5 years of development, and your crate will certainly be incompatible, because serde crate is not following semver. Same goes for cc, anyhow, syn and a few others non-semver crates. OTOH if you specify new versions, even very latest ones, then -Z minimal-versions will work, and Cargo's dependency resolution will figure out a set of crates it can use. If your deps are too new, then Cargo will just use older version of your crate, which had previously-latest versions.

So paradoxically, to support old Rust, the best way is to bump dependency versions.

5 Likes
17

Very cool feature! I do have feedback as well:

For opentelemetry-stackdriver:

  • " Imprecise dependency requirement yup-oauth2 = 6". I will generally avoid putting 6.0.0 and use 6 directly. Moreover, I find the advice to cargo install cargo-edit; cargo upgrade actively harmful, because I don't think crates should update their Cargo.toml dependency requirements en masse. For example, this recently got me into trouble when a crate forced a futures 0.3.18 requirement, then 0.3.18 had UB issues and was yanked for a while before 0.3.19 was released. My policy is generally to pick up the latest precise version when I start depending on a new crate and stick with that. I think the minimal versions risk ends up not being very high especially for dependencies that I adopted a long time ago. (Hmm, reading your take on serde = "1" I can understand your point. Perhaps there should be some middle ground, say, if the semver-major version is no more than 6/9/12 months old imprecision should be allowed?)

  • "Using outdated edition for no reason": lib.rs seems to think this crate depends on 1.56, but in fact it's tested in CI with 1.49. So I'm not sure why it thinks that. (Hopefully this becomes easier in the future as crates adopt actually using rust-version.)

For quinn:

  • " Buggy README path" would be nice this could link to the actual Cargo bug?

  • "README missing from crate tarball" would this be related to the previous one?

Given that I disagree with a bunch of these recommendations, it would be useful if I could filter them and/or transpose the ordering from crate/type to type/crate. Also, since badges are kinda deprecated (The Manifest Format - The Cargo Book), it doesn't seem like a great mechanism to rely on to signal stuff. Maybe it could also count if the crate's repository is archived?

I disagree. There seems to a common standard where many of the crates I look at at least try to maintain 6 months of compatibility (which is closer to 4 releases). See some discussion here.

Also another recommendation could be to get rid of the authors metadata, following RFC 3052.

18

Very nice. Particularly awesome that you added an Atom feed!

I subscribed to mine. Yesterday I got a bunch of updates, all labelled "Internal Error" with a subtext along the lines of "We couldn't check this crate at this time, because: deadline elapsed. Please try again later".

Checking the destination (the dashboard), it is just showing what it showed beforehand and has no traces of this error. In fact, it seems to be some internal thing. Should it really be bubbled up to users?

19

I will generally avoid putting 6.0.0 and use 6 directly.

Please don't do that! It's not as helpful as you may think, and it backfires for the very people who would need to use an older version. I've written a separate post about this.

1 Like
20

This topic was automatically closed 90 days after the last reply. We invite you to open a new topic if you have further questions or comments.