This is exactly what I was wondering as well. While I think a collection like this is generally a good thing, I think it also introduces a few idiosyncrasy such as the above situation.
Personally, I’d prefer something akin to a “blessed” yet still bastard-love-child of awesome-rust and this project. This way you also avoid things such as the log4rs / env_logger opinions because you can list both and state why one would pick one versus the other in certain situations and still maintain a very curated list (i.e. not listing every single log crate out there). You also don’t have to worry about a project breaking do to a crate swap, or constantly tracking changes to stdx.
Can’t we just have an official list of “blessed” packages encouraged to be used by Rust core team? It could come with a list of “wanted” packages that core rust team would like to have produced by community.
Yes, that could probably happen. In some sense those are the packages under rust-lang, but also those could be these. In my opinion it’s probably not the work of the core team though, since they are few and have varying interests.
I really like the idea of a curated list of crates, but I see no reason for using stdx or a similiar collection as a dependency. Adding dependencies is so simple with cargo. Packages depending on stdx should not be allowed on crates.io since they pull many unneeded dependencies.
I really don’t think either crate should be exposed by stdx. libc is a very popular create because it is a dependency of many other libraries; both libraries are really second order-libraries (libraries for libraries).
@stebalien I’d argue that std is exactly a “library for a library”, so
putting it in stdx doesn’t seem that crazy. Although it’s perhaps a bit
"rude" for a simple library to depend on stdx, it’s a great way to get
started (and “free” if your consumer depends on it too!).
Half joking: if stdx 0.102 is for Rust 1.2.0, this scheme will overflow in “only” 11 years when Rust 1.100.0 is released. (And as mentioned elsewhere, not releasing Rust 2.0 for a long time would be a sign of success IMO.)
I think it is redundant with crates.io.
I’d really prefer an update of crates.io to mention (with keywords/categories etc …) that these libraries are for generating random numbers and this one in particular is considered the best in most situations.
The workload looks similar but it avoids having an additional layer.
It would be great if crates.io were more helpful for discovery. Telling people which ones are best-of-breed will require human curation though. If crates.io develops these features then maybe the work that goes into stdx can be folded into crates.io.
Add a usage faq. A guide with simple recipes for common tasks, hopefully that combine the libraries in interesting ways. Doubles as a test suite (*).
Get reexported macros working
(*) Part of my ambition for stdx is to help with Rust regression testing. stdx provides a set of specific revisions of popular libraries that can be exercised by tools like crater and ctrs, and if we can also provide a test suite that exercises them all together, that is really useful for future compiler writers.