PSA: Movement of rust-lang crates

announcements
1

Good evening rustlers! Today the libs subteam has implemented RFC 1242 which changes where a number of the rust-lang crates are located, and to ensure that the word gets out I’d like to summarize what happened here.

tl;dr; Crates are now found in the new rust-lang-nursery and rust-lang-deprecated organizations, and those in the nursery may eventually move to rust-lang while those in deprecated would appreciate an active maintainer!

RFC 1242 Recap

The main purpose of RFC 1242 was to detail an explicit plan for grown a larger set of ‘official’ libraries outside of std as well as set forth a path to move large sets of functionality into the standard library itself. The large number of crates that are currently in rust-lang are a bit of a mishmash of high to low quality in varying degrees of upkeep. In order to organize this, a vision was spelled out for how crates become an “official” crate of the rust-lang organization. The life cycle looks like:

  1. Crates first enter the rust-lang-nursery organization as “0.X.Y” crates.
  • This represents no major commitment on behalf of rust-lang but rather simply a “trial period”.
  • The original author of the crate maintains control, approving PRs, editing code, etc.
  • The broader community is encouraged to participate in development and crates in the nursery are more broadly advertised.
  1. At some point, crates in the nursery either move to rust-lang via an accepted RFC or to rust-lang-deprecated/another owner at a point decided by the library subteam.
  • An RFC for movement to rust-lang is required as it signifies that ownership is being transferred to the community, and buy in is important. Additionally, diving into API design and rationale is always useful!
  • Once in rust-lang, the crate is then owned by the Rust community at large, and major changes are governed by the library subteam in consultation with the original maintainers.
  • Future significant changes to the library require an RFC.
  • Crates in rust-lang are advertised as “core Rust” packages.
  1. Some crates may eventually move into std itself, at which point the library subteam will call an FCP after which the library will be folded in if accepted.
  2. If a rust-lang crate becomes stale over time, an RFC is written to move it to the rust-lang-deprecated organization.

If you’ve got any questions, please feel free to consult the RFC itself, or just ask questions here!

Existing Crates

Given that background, here’s a summary of where all current rust-lang crates are now located:

Nursery Crates

  • bitflags
  • getopts
  • glob
  • libc
  • log
  • rand
  • regex
  • rustc-serialize
  • tempdir
  • uuid

Deprecated Crates

These crates will continue to live in rust-lang-deprecated for a few reasons such as:

  • Niche functionality that doesn’t necessarily justify being an “official rust-lang crate”.
  • The crate is already deprecated in favor of another implementation (e.g. url in favor of rust-url).
  • The API of the crate is in such need of an overhaul that it needs to radically change to be considered to move back into the nursery. This isn’t an indication that the functionality itself is deprecated, simply that it’s being messaged that it needs to be overhauled.

If you’d like to become the maintainer the library subteam is more than willing to transfer ownership to you!

  • fourcc
  • hexfloat
  • num
  • rlibc
  • semver
  • term
  • threadpool
  • time
  • url

What does this mean for me?

In short, this doesn’t actually mean much for the consumers of these crates. All crates will retain the same name on crates.io, and the crates aren’t tagged as "nursery" or “deprecated”, so the compiler won’t be issuing warnings or anything about usage of any of these crates.

This change is largely intended to message clearly what crates are “getting ready for stabilization” and which are “in need of dire overhaul”. It’s highly likely for crates like time to move from the deprecated area to the nursery after receiving some API scrutinization, for example.

6 Likes
2

I’ve already said previously that I’d adopt semver, if that’s still cool.

3

I’m willing to maintain (but am unlikely to improve) the term crate if nobody else wants it (although you’d probably be a better maintainer as you wrote almost all of the code).

4

I could take care of num crate as I often find myself in need to use that (and if there is no one who want to do so).

5

I also use num, and am willing to co-maintain if you like.

6

Thanks for volunteering! I’m also willing to take over rlibc, and we’ll talk more about transferring the crates in the libs triage meeting this week if we get the chance, so I’ll get back to you!

7

That would be great.

8

The numeric traits in num are very useful for playing with generic mathematics, such as Float and Signed. I hope that they could be added in std::num. What is the current status of num-reform RFC?

9

The num-reform RFC was what led to the creation of the num crate in the first place. It’s still not exactly clear what we want to eventually stabilize.

10

Right. In particular, the hope was that we could explore various “numeric hierarchies” using traits outside of std for a while. It’s worth remembering that there was a long pre-1.0 history of trying different traits, and we still weren’t in a mature place.

I would really love for some domain experts to lead the charge, here!

11

From my personal experience, we only need six primitive traits (Int, UnsignedInt, Signed, Float, Zero, One) in std::num to cover most use cases. They provide very basic functionalities for generic mathematics. Other numeric hierarchies should left to external crates.

2 Likes
12

As an update, the libs team didn’t have time to talk about this topic this week in triage, but we’ll be sure to get to it next week!

13

Alright, we discussed this at the last triage meeting and we’re all good with the transfers, if you want to sync up with me on IRC acrichto I’ll get the crate transferred to you!

14

I have some interest in maintaining the threadpool crate. We use it for a few projects internally at my job and am fairly familiar with internals.

15

Thanks for volunteering @frewsxcv! The threadpool crate has now been transferred to you.

16

@alexcrichton would you create GH organization for me and @cuviper and move num into it?

17

@hauleth I’ve replied in a PM, we can discussion off-thread from here :smile:

18

What’s the status of the num crate? I want to contribute code to it. The crates.io metadata indicates that the transfer hasn’t happened yet.

19

It’s been transfered (FWIW, github will auto-redirect transferred projects, so the github.com/rust-lang/num “Repository” link reported on crates.io will actually get you there).

20

We haven’t published any new versions of num yet, but probably should soon. We’re definitely taking contributions though!