As for a central batteries-included crate, its been tried a couple of times (e.g. stdx, ergo). Some things that I think would help drive it forward
- RFC 3243 [1] to allow for a central "front" for these crates without having to actually compile what you don't need or feature flags
- A compelling reason for people to adopt it. For a lot of existing projects, there isn't much motivation. I see the biggest benefit mostly being for prototyping and new users, so they need to cater to these users. Don't just re-export existing crates but lay things out in a natural, discoverable way. Also consider making things easier by keeping the Rust language knowledge to a minimum for end-users (even avoiding lifetimes where possible), don't overwhelm users with choices that won't matter in these contexts, etc. If the user needs more performance or flexibility, they can scale up to the crates being wrapped
I'm interested in working in this space but need to wrap up some other projects first. If anyone wants to work on this and is looking for a mentor, feel free to reach out to me.
[0] https://rust-lang-nursery.github.io/rust-cookbook/intro.html
I could imagine that security conscious products (medical, automotive, network applications) would feel more comfortable if there was a definitive release that could be cited as the basis for the work. Hardly absolves the requirements that would go into a regulated product, but it could be a minor step in the right direction.
>Don't just re-export existing crates but lay things out in a natural, discoverable way.
Complete agreement there. If there were ever to be a sanctioned "batteries crate" it needs to be more than slapping together a meta directory and calling it a day. I think the Lua Penlight project stands as an example of this.
- Command line parsing (more feature rich the manually iterating over args)
- (De)Compression: tar, zip, gzip, bzip2
- CSV parser
- Date time
- Hashing: md5, sha1, sha256
- HTTP requests
- Logging
- Random generation: ints, floats, sampling, uuids
- Regex
- SQLite bindings
- (De)serialization: json, ini, toml, yaml
- System niceties: where is user home?, # of cpus?
Edit: tried to make the formatting less bad
I think regex, time, and crates like num_cpus would especially be nice to have. There's plenty of those types of crates where it feels like you can't compile a single project without seeing it float by as you build the dependencies.
https://doc.rust-lang.org/std/thread/fn.available_parallelis... — Rust 1.59