The Lib Blitz was a really exciting time seeing advancements in some crates and some hit 1.0, but the biggest take away I saw from it were the API guidelines that were published. I’m working through them in order to get nix to 1.0, and they’re full of very sage advice. I’d like to see efforts in the Libs Team expanding this knowledge to other areas related to developing great crates like:
- Example CI configurations for some of the bigger CI players, especially as this relates to cross-platform compilation and testing (like using trust). I’d especially like if this includes GitLab CI, which generally gets neglected with these kinds of things. The crates deepest in the dependency tree are most important to have cross-platform CI testing as possible. We wouldn’t support as many platforms as we do with
nixif libc’s CI testing wasn’t so robust. - This also means getting all supported platforms up to being supported in
rustup. That’s the only things stopping us from supporting DragonFlyBSD innixright now, that we can’t install it easily (same for OpenBSD I believe). It’d be good if there was better documentation and support around how to set up compilation and/or testing for other platforms either using QEMU, docker containers, etc. There’s knowledge hidden across a lot of different crates, but it’d be good to centralize that knowledge so everyone can benefit. - Clippy and rustc’s lints are very powerful for enforcing good code style.
gtk-rsandwinapi-rsgo beyond these lints to enforce additional code style rules that accelerate development. It’d be good to see more effort towards adding more lints to rustc and clippy and to also enable more of them by default. - More validation of crates before uploading to crates.io. Right now a lot of failures when publishing to crates.io happens really late in the process, but it’d be great if the API guidelines above was an automated check run my cargo or a cargo subcommand. The easier the guidelines process is, the more likely people will try to follow it.
Regarding specific libraries I’d like to see some focus on the bottom-of-the-stack: platform libraries. This means winapi-rs, libc, mach/CoreFoundation-sys/IOKit-sys, ioctl-rs, and nix (note: I maintain this crate). These are all very low-level, in that they interact with the system kernel or user space libraries associated with the OS. It’s very hard to build software on an unstable foundation and these libraries are very foundational. The biggest issue is that libc needs a 0.3 release to fix various issues with it, but nobody wants to touch it. That’s the biggest wart I see, but many of these crates need work to build off the progress that’s been made in the ecosystem, like relying on libc because of its good CI testing and validation rather then declaring their own types. It would be helpful to get enough eyes on these foundational OS crates to set them on a path to 1.0 as part of a lib blitz, and maybe help them recruit some more devs to do that work.