-
Notifications
You must be signed in to change notification settings - Fork 12.8k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Integrate remaining parts of wanted-libraries into std #2729
Comments
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. |
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. |
@brson points out I was too hasty to close this. Concerning followup points:
I'll change this to a tracking bug on ... making the standard library meet the note-wanted-libraries list, say? |
Somewhat related is #2045 |
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. |
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. |
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. |
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. |
@Lenny222: Hahaha, I like it. |
This issue is too broad and unactionable. |
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.
The text was updated successfully, but these errors were encountered: