You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
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!
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.
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).
@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.
Activity
thestinger commentedon Aug 27, 2013
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 commentedon Oct 15, 2013
Nominating.
brson commentedon Oct 15, 2013
cc #9343
I think there are three destinations for extra modules:
Some notes:
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 commentedon Oct 17, 2013
1.0, backwards-compat
Seldaek commentedon Oct 31, 2013
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 commentedon Jan 26, 2014
@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 commentedon Jan 26, 2014
Does libextra (or the split crates) belongs to Rust's "standard library"?
67 remaining items
Move extra::json to libserialize
auto merge of #12453 : alexcrichton/rust/move-json, r=brson
auto merge of #12896 : alexcrichton/rust/goodbye-extra, r=brson