Integrate remaining parts of wanted-libraries into std

[kud1ing]

The author of https://github.com/grahame/rust-csv has expressed that he lacks the time to keep up with Rust's changes. If "rust-csv" was part of libstd it would be guaranteed to be in a usable state. This is also true of several of the linked projects on the note-wanted-libraries page. We want a rich standard library. There's integration work to do, in addition to library-writing of our own.

[graydon]

Yes, it should. We've discussed this in detail in the past but not yet committed our resources to library work, still focused on language-work itself. This will change in the period between committing to language-stability measures and committing to a stable 1.0 library API.

See https://github.com/mozilla/rust/wiki/Note-wanted-libraries for some notes on stuff we'd like. Feel free to add stuff there and/or add extra links.

Closing this for now; std-expansion work is a known long-term issue.

[brson]

There are several out of tree rust projects that may be appropriate for std. Certainly CSV seems appropriate to me.

I don't want to remain in the position where we feel compelled to put stuff into the standard library just to keep it building though. As cargo matures I am starting to think that we should push everything that rustc doesn't depend on into external repos (and crates) for cargo to manage. The most important of those of course could be hosted and maintained by Mozilla.

[graydon]

@brson points out I was too hasty to close this. Concerning followup points:

• I agree that we should move to separate repos that we manage with cargo (or, um, rust get or whatever we wind up calling it).
• I doubt we can get to a point where rustc does not depend on std, nor even sure that's desirable, but that's not an argument for them to always be maintained in a single repo. They are now, that's all. They can drift to separate repos once things settle down more.
• I do think "so it can keep compiling" is a valid reason to have mozilla maintain something. Or more generally: "so it gets QA attention as part of the language-development effort mozilla is funding". Keeping something in one of our repos is exactly a signal/commitment to that sort of support.

I'll change this to a tracking bug on ... making the standard library meet the note-wanted-libraries list, say?

[graydon]

See also #2343, #2640

[kud1ing]

Somewhat related is #2045

[erickt]

Would it be possible to have the buildbots compile all the crates, say, once a week or so until the language stabilizes? That could alert us to packages that are bitrotting. We could make a cargo-central policy that if the crate hasn't been fixed after X days, one of the core devs can fork to update the syntax until a new maintainer can take ownership.

[brson]

@erickt #1453 is about that. It's one of my biggest wishlist items.

[kud1ing]

Are you suggesting that the "rich standard library"should live in a separate repository or that each of the modules should live in separate repositories?

What are the benefits? Size?

I think people could live with the first but it could get annoying if they had to "cargo install" every module they would get out of the box with other languages. Also think of potential trouble with firewalls. In the Haskell world people bundle separate modules in the Haskell Platform as the goto platform.

[brson]

This is a little OT but my dream is that every individual component, including things like rust-llvm, core, std, rustc, is a cargo package and the entire stack is bootstrapped by cargo. I'm not considering so much the actual decomposition of the standard library, whether it's one big crate or lots of little crates. In either scenario I would expect that all of the goodies that compose a rich standard library would be installed by default, by cargo.

[kud1ing]

I jokingly suggest we should use https://github.com/erickt as the central place for the rich standard-library. Erick is already maintaining 12 of 27 repositories from cargo-central anyway.

[erickt]

@Lenny222: Hahaha, I like it.

[kud1ing]

This issue is too broad and unactionable.
I think the Wiki page serves this better: https://github.com/mozilla/rust/wiki/Libs