Rust libz blitz!

libs
21

thread-id is another fundamental crate.

22

Won’t thread-id be subsumed by std::thread::ThreadId? #21507

23

I took the liberty of adding bytes, syslog, lzw, ring, openssl, petgraph, daggy, typenum, image, cfg-if, and itertools to the crate list. Others suggested may be good candidates, but I have less certainty.

nom I think is obviously an important and high-quality crate, but I’m not sure I consider parser generators in scope here. That’s not something I usually associate with batteries included standard libraries.

24

There are a number of additional library ecosystem tasks that don’t fit into the blitz structure that I would like to move forward sometime this summer. Just to telegraph that a bit, here is a braindump.

  • Standard library survey - Last year the libs team started a survey of batteries included standard libraries, but never finished. The intent was to get a handle on the set of features typically expected out of a language’s runtime stack, and then identify areas where we are lacking and need to focus effort.
  • rand design review - The rand crate has long been unsatisfactory to the libs team, and needs some focused design work. People that love random numbers are needed. I know @bstrie indicated he was keen about this.
  • chrono design review - This crate provides comprehensive date/time solutions, but it my experience using it (and I gather others’), it can be difficult to discover how to do some fairly basic tasks. I recall my biggest pain point was understanding how to deal with all the timezone concerns that are represented in the type system. It may be that just writing cookbook examples for a number of tasks would help. It also still depends on the time crate, which is destined to be deprecated. cc @lifthrasiir I hope you will be amenable.
  • A 1.0 crate scoreboard - Just a simple motivator. Create a thread on urlo that lists, in reverse chronological order, the crates that hit 1.0, their dates, and their authors. This clearly would be gameable, but that’s fine. At least it conveys consistently that 1.0 crates are important, and crate authors should endeavor to get there. It would be pretty easy to maintain with a script. Once a week post an update to the op, and a comment indicating all the updates and thanking the crate authors.
  • A cookbook roadmap and urlo thread - I’d like to define what a 1.0 cookbook looks like so there’s a clear destination, make regular point releases and status updates.
25

I’ve just discovered that docs.rs displays a crate’s GitHub README. Can you tell the difference between these two pages:

I was quite confused, and I think all this redundant information makes a poor experience.

In any case, we have no guidelines for crate READMEs, and since this is a crucial part of the documentation UI, it seems like we must establish some, then go back and review the crates we’ve done. cc @dtolnay

4 Likes
26

Yep, I'll have to bring this up in the front page styleguide RFC https://github.com/rust-lang/rfcs/pull/1687.

27

I've just discovered that docs.rs displays a crate's GitHub README

I would just like to note that this has nothing directly to do with GitHub (it just happens to be the same in approximately 100% of the cases), if you were to have a package with the source hosted elsewhere it should work just the same. Judging by this code from docs.rs it is based on the package.readme key in the packages Cargo.toml + a default if not specified, as described in The Manifest Format:

# This points to a file in the repository (relative to this `Cargo.toml`). The
# contents of this file are stored and indexed in the registry.
readme = "..."
28

I needed a parser, looked at many of them and wasn't satisfied with either, but I agree it is a relatively niche tool.

However I would like to nominate some more XML-related crates. I see xml (should be xml-rs?) is already in, but some DOM should also be included. I see a couple of candidates for that: sxd-document (+sxd-xpath), minidom, elementtree, rquery, treexml, xmltree. They are mostly equivalent, so some should be chosen.

29

Rust libz blitz status update 2017-05-12

Ok, here’s what we accomplished this week.

Also @dtolnay @danburkert @SimonSapin @sfackler and @alexcrichton reviewed tons of stuff.

Wow. So that’s pretty amazing. Thanks everyone!

6 Likes
30

OK, one more thing for today.

The walkdir crate is scheduled for 6/13, has no assigned lead, and I do want to start getting these evaluations going more weeks in advance. I know we’ve only had one round to crib off of so far (log, but if anybody has an inclination to lead the walkdir evaluation, I can help walk them through the evolving process. I’ll be on vacation next week, but the one following we can get started. Alternately, if somebody is up to getting walkdir started next week @dtolnay can assist.

@dtolnay will be starting the reqwest evaluation soon.

2 Likes
31

I added a link to the reqwest evaluation.

32

I added a link to the libs team meeting about log.

https://air.mozilla.org/rust-libs-team-meeting-2017-05-16/

33

I’ve filled in the tracking issue and cookbook issue for the log crate:

34

Status update 2017-05-19

There has been a ton of great libz blitz progress this week. We are going to need even more help to keep up the momentum! Contribution opportunities are in bold.

log

reqwest

url

flate2

memmap

Cookbook

API guidelines

Thanks everyone!

4 Likes
35

It’s been suggested to me that base64, data_encoding, tar, and backtrace are all appropriate here. Sounds right to me. Any other opinions?

36

hex is along similar lines, and apparently it’s the best place to get hex conversion.

37

This graph shows the great effect the libz blitz has been having for the log crate. We still need lots more help! Please check the tracking issue for opportunities to contribute.

libz-blitz-log-graph
libz-blitz-log-graph.png1158×287 16.2 KB

3 Likes
38

I updated links in the op. There are already cookbook tracking issues for mio and walkdir.

39

I updated the crate list per the last few suggestions, and attempted to generalize the categorizations there a bit.

40

The walkdir review is scheduled for 6/13, and the intent is to start evaluations one month ahead of time, so it’s behind schedule. It still doesn’t have a lead assigned. Is anybody interested in leading the walkdir evaluation, starting this week? It doesn’t require a great deal of experience, since the entire process is outlined in the checklist, and there are previous examples to crib off of.

If not, I will begin the walkdir evaluation on Friday.

The error-chain review is scheduled for 6/27, which means @aturon needs to get that evaluation rolling soon as well.