Skip to content

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

@thestinger

Description

@thestinger
Contributor

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!

Activity

thestinger

thestinger commented on Aug 27, 2013

@thestinger
ContributorAuthor

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

brson commented on Oct 15, 2013

@brson
Contributor

Nominating.

brson

brson commented on Oct 15, 2013

@brson
Contributor

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

catamorphism commented on Oct 17, 2013

@catamorphism
Contributor

1.0, backwards-compat

Seldaek

Seldaek commented on Oct 31, 2013

@Seldaek
Contributor

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

brson commented on Jan 26, 2014

@brson
Contributor

@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

liigo commented on Jan 26, 2014

@liigo
Contributor

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

67 remaining items

added a commit that references this issue on Feb 24, 2014
added a commit that references this issue on Feb 24, 2014
added a commit that references this issue on Mar 15, 2014
fc7a112
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

No one assigned

    Labels

    No labels
    No labels

    Type

    No type

    Projects

    No projects

    Relationships

    None yet

      Development

      Participants

      @olsonjeffery@flaper87@seanmonstar@alexcrichton@brson

      Issue actions

        split up libextra (move some out to rustpkg packages, some to libstd) · Issue #8784 · rust-lang/rust