Skip to content
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

Closed
kud1ing opened this issue Jun 27, 2012 · 12 comments
Closed

Integrate remaining parts of wanted-libraries into std #2729

kud1ing opened this issue Jun 27, 2012 · 12 comments
Labels
C-enhancement Category: An issue proposing an enhancement or a PR with one. E-hard Call for participation: Hard difficulty. Experience needed to fix: A lot.

Comments

@kud1ing
Copy link

kud1ing commented Jun 27, 2012

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
Copy link
Contributor

graydon commented Jun 27, 2012

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.

@graydon graydon closed this as completed Jun 27, 2012
@brson
Copy link
Contributor

brson commented Jun 27, 2012

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 graydon reopened this Jun 27, 2012
@graydon
Copy link
Contributor

graydon commented Jun 27, 2012

@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
Copy link
Contributor

graydon commented Jun 27, 2012

See also #2343, #2640

@kud1ing
Copy link
Author

kud1ing commented Jun 29, 2012

Somewhat related is #2045

@erickt
Copy link
Contributor

erickt commented Jul 2, 2012

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
Copy link
Contributor

brson commented Jul 2, 2012

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

@kud1ing
Copy link
Author

kud1ing commented Jul 4, 2012

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
Copy link
Contributor

brson commented Jul 4, 2012

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
Copy link
Author

kud1ing commented Jul 4, 2012

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
Copy link
Contributor

erickt commented Jul 5, 2012

@Lenny222: Hahaha, I like it.

@kud1ing
Copy link
Author

kud1ing commented Mar 22, 2013

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

@kud1ing kud1ing closed this as completed Mar 22, 2013
celinval pushed a commit to celinval/rust-dev that referenced this issue Jun 4, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
C-enhancement Category: An issue proposing an enhancement or a PR with one. E-hard Call for participation: Hard difficulty. Experience needed to fix: A lot.
Projects
None yet
Development

No branches or pull requests

4 participants