3 ms·
A few ideas: 1) Remove the ability to unpublish / yank crates. A published crate should be immutable, but the crate's metadata should always be updateable by t
by thesuperbigfrog 7y ago
A few ideas:
1) Remove the ability to unpublish / yank crates. A published crate should be immutable, but the crate's metadata should always be updateable by the maintainer.
2) Improve the metadata that describes a crate so that it is easy to tell if a crate should be used. For example, is the crate beta quality? Was a serious error found in the crate and it needs to be marked as "not safe"? Is it a Long-Term Support release? Etc.
3) As a culture, disallow trivial crates. No "is-odd" or similarly low effort crates. These just add bloat since the have so little functionality compared to their overhead. If your crate's toml is larger than the crate's code, you are doing it wrong.
- chc 7y agoIronically, "no trivial crates" is almost exactly the opposite of what the article seems to want, which is only small crates so you're not importing lots of needless bloat. It's hard to please everyone!
- raphlinus 7y agoI talk about this a bit, I'm in favor of at least medium granularity crates, but if they break down into smaller features, where different use cases will meaningfully choose different sets of features, use feature gates. So, for example, you might have a "string formatting utilities" crate with a "left-pad" feature. (Note: this particular example is unlikely because the `format!` macro in the standard library can do it just fine)