A number of good points have been raised above and elsewhere, so I’ll try to avoid repeating those and just offer some brief suggestions, noting first that I’m not hostile to the ideas raised here, but I don’t think they’re particularly necessary, and I think some of the other pain points brought up here (e.g. the UI on crates.io) and on HN and Reddit are as or more important than whether we have a blessed meta-package or not.
-
I strongly endorse the idea of enabling “meta-packages” without expressly endorsing any. Making the build and packaging tooling robust around this will enable the community to coalesce around the things which are valuable, and those can overlap in unique ways. Some of the best stuff going on in the Python ecosystem is around exactly those kinds of community-driven sets-of-libraries/metapackages, but the official tooling has lagged so badly that there are entire alternative distribution tools that have grown up around them (e.g. Conda etc.).
-
Put a high priority on supporting and shipping the in-work tool for supplying docs in a centralized location (presumably, ultimately, as part of crates.io), and work at a cultural level to make that the default location for documentation.
-
This will help enormously with discovery, as well as providing the opportunity for integration with the “docset” tools out there (Dash/Zeal/etc. and anything compatible with that). I know I find that really nice when I want to go look at something for Elixir: you can just pull up hexdocs.pm, and those docs can be integrated into any docset tool.
-
As part of that effort, build tools to support the
docs/various-content.mdmodel which is used for the Rust docs themselves (which both @steveklabnik and I have taken abortive stabs at in the past) and make those integrate with the documentation hosting as well.
It is hard to overstate how significant an impact I think this will have on the community.
-
-
Look at building out something like Ember Observer. When I’m evaluating a Ember add-on for integration into our application, I evaluate it there first. This is a community-maintained resource, and there are definitely some things that would need to be handled differently for Rust crates than for Ember add-ons—but there are more than a few similarities, too.
Each of those could very well be integrated in with the broader idea you’ve thrown out, but they can also be useful regardless of whether any official Rust Platform shipped, and would help address many of the same underlying issues.
Separate from all of that: I think the idea of shipping a small set of standard tools (rustfmt, clippy, etc.) is great, and that should definitely happen. Small support applications feel very different to me (and, I suspect, to most other developers) than do libraries, especially libraries which can basically function as standard libraries.