split up libextra (move some out to rustpkg packages, some to libstd)

[thestinger]

The plan seems to be that we'll move some of this out to rustpkg, and move a conservative set of modules to libstd that we are willing to stabilize/standardize.

As far as I can tell there's still no issue open for this, so here we are!

[thestinger]

Tagging as an RFC, because we need to go through the modules and decide whether each one is a reasonable module to clean up and freeze with a stable (mostly) interface.

I think Go is a good case study here because they have lots of the cryptography and Unicode support outside of the main repository.

[brson]

Nominating.

[brson]

cc #9343

I think there are three destinations for extra modules:

• Move to std. Probably very few should go in std.
• Move to it's own package on GitHub, integrate with Rust CI.
• Move to it's own crate in the main repo - probably just for things that rustc depends on.

Some notes:

• I've long resisted moving test into std because it pulls in many other modules.
• ebml is required by rustc but shouldn't really be used by anything else. Does it get it's own crate in the main repo?

[catamorphism]

1.0, backwards-compat

[Seldaek]

Just two cents from a user here. From what I have seen in other language the "batteries not included" approach can be quite frustrating. In node for example many very simple things require a package, and since there isn't really a list of packages blessed by the core language team or even by the community, newcomers can end up having to try many packages of dubious quality before they find one that fits. I can fully understand the fact that you need to reduce the scope to stabilize the core ASAP, but I hope you keep this in mind and think of a strategy for the future.

Either create a rust organization on github where blessed packages can be moved to, or maybe even rebuild a libextra later where popular and proven packages can be pulled in to form a stronger base language distribution (kind of like in PHP where anything you can possibly want is included, though I don't think we'd need to go as far).

[brson]

@Seldaek The intent is to have an offical rust incubator (http://github.com/rust-lang) where the official packages reside, along with a process for promoting community packages to official packages. Whether crates reside in the installed distribution or are built from remote repos, I hope we have a situation where it's clear what crates you should use for many common tasks and adding them to your project is easy. So I fully agree with you.

[liigo]

Does libextra (or the split crates) belongs to Rust's "standard library"?