[rust-dev] Migrating libs out of rust-lang/rust

Alex Crichton alex at crichton.co
Tue Jul 29 15:30:13 PDT 2014


Now that cargo is starting to become a larger part of the Rust ecosystem
it's time for some of the crates as part of the standard distribution to
move out of the main rust repository. This movement has been planned for
quite some time now, and it has only recently become possible with the
advent of cargo.

Starting today, we'd like to evolve crates not needed by rustc itself
outside of the compiler wherever possible. This will reduce cycle time on
development of these libraries, allow them to develop independently from
rustc, and hopefully allow them to be more focused in their target goals.

The process of moving crates out of the standard distribution will be an
ongoing and evolving one. We currently have the benefit of being able to
move the entire distribution forward in one atomic step with everything in
one repository, but this quickly becomes infeasible with many repositories.
We plan to implement any necessary infrastructure to ensure that the crates
move out of the rust repository maintain the same level of quality they
currently have.

To this extent, the current process for moving a crate out of the standard
distribution will be as follows:

1. A member of the core team will be contacted to create the repository
  `rust-lang/$foo`.
2. A PR will be made against `rust-lang/$foo` with the current copy of the
   code from `rust-lang/rust`. This PR will be expected to have the
   following source structure:

     * Cargo.toml - a manifest to build this repo as a cargo package
     * .travis.yml - configuration to run automated tests on travis. A
                     sample can be found for hexfloat [1]
     * LICENSE-{MIT,APACHE} - copied over from rust-lang/rust
     * src/ - the same source structure as the folder in rust-lang/rust

3. A PR will be made against `rust-lang/rust` which will flag the relevant
   library as `#[deprecated]` with a message pointing at `rust-lang/$foo`

In order to ensure that these repositories continue to stay up to date, we
will have the following process in place:

1. Each repository will be hooked up to Travis CI and will be built each
   night once the new nightlies are available.
2. A status page [2] is provided to get a quick glance at the status of all
   officially supported repositories.

The amount of infrastructure around keeping these repositories up to date
will likely change over time, but this is the current starting point for
automation.

[1]: https://github.com/rust-lang/hexfloat/blob/master/.travis.yml
[2]: http://buildbot.rust-lang.org/travis/travis.html


More information about the Rust-dev mailing list