Strategy for stabilization non-std crates

[brson]

For 1.0 we're only going to stablize std. We need to figure out what to do with all the other crates. @alexcrichton has some ideas.

[reem]

/cc me

[alexcrichton]

Here are my current thoughts on this. Nothing is official of course, just a bunch of proposed strategies to deal with all these crates:

Facade crates we must ship

• alloc
• collections
• core
• libc
• rustrt
• sync
• unicode
• rand

Suggested strategy: Disallow explicit extern crate foo to the crates via stability lints. The stability lint will look at extern crate foo and then inspect the crate attributes of the crate foo for stability lints to perform this check. This means that these crates can all be #![experimental], disallowing access to them.

Other suggestions:

• we may wish to reserve these names in crates.io

Compiler implementation details we may want to ship somehow

This is a listing of crates which the compiler uses as implementation details. These apis are not in a state of which they should be stable, but they are quite useful to the community at large (many users!).

• arena
• log
• term
• time
• getopts

Suggested solution: Provide all of these crates officially through crates.io instead. Each crate will start with #![cfg_attr(source_build, experimental)]. This means that uploaded cargo packages will not be experimental, but published versions via the standard distribution (built with --cfg source_build) would be experimental. This means that to use the crates you will have to depend on the crates.io package, not the distributed package.

Crates tied to the compiler implementation itself

These crates cannot be modified without changing the compiler itself. Conversely, the compiler can never change because these crates are not changed in lockstep. The apis are not quite what we'd like to stabilize at this time, however.

• test
  • Very little API surface bound by librustc, in the worse case we can just add more surface area over time.
  • Must be able to import test::Bencher, however, with the one method iter and the field bytes.
• serialize
  • The Decodable and Encodable traits are tied to the compiler's deriving implementation.

Suggested solutions:

• test: Ship an #[experimental] libtest (compiler injected extern crate statements to experimental crates are ok), but create std::test with Bencher inside of it. Bencher will become a trait instead of a struct.
• serialize: Move Decodable and Encodable to the standard library, try to land @erickt's improvements before 1.0, and mark serialize as #[experimental]. Move the crate itself to cargo and require existing users to use the crate through cargo instead.

Misc crates

• native

This crate will likely just be removed with rtio work

Crates we want to ship

• std

No questions here!

Compiler implementation details we do not want to ship

• flate
• fmt_macros
• graphviz
• rbml
• rustc
• rustc_back
• rustc_llvm
• syntax
• rustdoc

Solution: flag all crates as #[experimental], do not provide any of them in crates.io either.

Crates to should be removed from the rust repo

• green
• rlibc
• regex
• regex_macros

I'm thinking of removing these entirely from the repository in favor of packages in crates.io. Each of these can be versioned speparately from the standard Rust distribution. Note that regex_macros won't be usable outside of the nightly channel of Rust.

TODO list

• Implement extern crate linting
• Add Cargo.toml to the cargo crates above, publish them at crates.io when it's online.
• Remove libnative
• Remove libgreen
• Remove rlibc
• Remove regex/regex_macros
• Ensure all crates are #![experimental] other than std (or cfg_attr(experimental)) depending on which one it is
• Move Bencher to std
• Move Encodable and Decodable to std

[steveklabnik]

Note that regex_macros won't be usable outside of the nightly channel of Rust.

This isn't true anymore, as macros will end up stable before 1.0.=

[huonw]

@steveklabnik regex_macros is a syntax extension, not a macro-rules macro.

[huonw]

On that note:

Remove regex/regex_macros

Regexes are used in the test harnesses (both libtest and compiletest) and liblog, so we may want to do the same trick to provide them officially. (Or just remove the support, of course, but filtering tests is quite nice.)

However, I don't know how/if we can get the versions linked into libtest and liblog to reconcile with the one provided officially. shrug

[alexcrichton]

We could in theory ship the regex crates as #[experimental] like some other libraries, but distribute them as not-experimental. That would allow us to have the distributed liblog and libtest depend on libregex, but you wouldn't be able to directly use the shipped versions.

I was thinking that the functionality was small enough that it's ok to remove, but if it's important enough we can keep them in tree.

[Gankra]

How does not stabilizing the facades affect #[no_std]? Is that something we'll be supporting in 1.0, or will they have to stay on the nightlies?

[alexcrichton]

For now crates relying on #![no_std] will need to use nightlies or some other libcore than the one we distribute (as it will be experimental)

[steveklabnik]

@huonw oh yeah, duh!