Deprecate more in-tree libs for crates.io

[alexcrichton]

This commit deprecates a few more in-tree libs for their crates.io counterparts.
Note that this commit does not make use of the #[deprecated] tag to prevent
warnings from being generated for in-tree usage. Once #[unstable] warnings are
turned on then all external users will be warned to move.

These crates have all been duplicated in rust-lang/$crate repositories so
development can happen independently of the in-tree copies. We can explore at a
later date replacing the in-tree copies with the external copies, but at this
time the libraries have changed very little over the past few months so it's
unlikely for changes to be sent to both repos.

cc #19260

[Gankra]

Was the decision/discussion for these recorded anywhere?

[liigo]

This is not an rfc, reviewers will make decision.
2014年12月14日 上午7:36于 "Alexis Beingessner" notifications@github.com写道：

Was the decision/discussion for these recorded anywhere?

—
Reply to this email directly or view it on GitHub
#19820 (comment).

[alexcrichton]

@gankro I haven't been able to dig up any notes just yet, but in general we're not willing to commit to any library in-tree at this time other than the standard library. As a result we have a large number of useful crates in-tree (such as all of these) which we would still like to provide. By providing these crates in crates.io we get a number of benefits:

• All crates can be rapidly iterated on as necessary because development happens independently of the compiler.
• Each crate can be used on the stable channel of Rust.
• Distribution on crates.io means you don't have to wait for the next release of Rust to get bug fixes or new features from these libraries.

Note that this is not just removing these crates. We plan to continue officially supporting them in the rust-lang organization and fix bugs etc. When we have time to scrutinize their APIs we may be able to fast-forward them to 1.0 as well, and possibly even bring it back in tree, but until that time we need a way to retain all of this functionality in the stable channel of Rust at 1.0.

[Gankra]

👍

[thestinger]

The regex crate is used by the test crate and exposed in the public API. What is the plan for handling that?

[alexcrichton]

The story of the test crate is one of the open questions of the stabilization bug, and I would like to leave that question to later. At worst we must freeze our regular expression syntax implemented today for filtering tests, where at best we remove the dependency altogether in favor of simply substring matching.

[sfackler]

I'm running into a lot of warnings trying to use the out-of-tree versions of these crates. What's the plan for dealing with them? Everything works fine, but it's really noisy.

   Compiling postgres v0.2.0 (file:///home/sfackler/rust/rust-postgres)
warning: using multiple versions of crate `regex`
tests/test.rs:4:1: 4:23 note: used here
tests/test.rs:4 extern crate postgres;
                ^~~~~~~~~~~~~~~~~~~~~~
note: crate name: regex
tests/test.rs:4:1: 4:23 note: used here
tests/test.rs:4 extern crate postgres;
                ^~~~~~~~~~~~~~~~~~~~~~
note: crate name: regex
warning: using multiple versions of crate `log`
tests/test.rs:4:1: 4:23 note: used here
tests/test.rs:4 extern crate postgres;
                ^~~~~~~~~~~~~~~~~~~~~~
note: crate name: log
tests/test.rs:4:1: 4:23 note: used here
tests/test.rs:4 extern crate postgres;
                ^~~~~~~~~~~~~~~~~~~~~~
note: crate name: log

[alexcrichton]

@sfackler are you sure the entire dependency tree is using libregex/liblog from crates.io? We're cutting down the size of the standard distribution to just one crate (the standard library), so you in general shouldn't be receiving those warnings as all crates migrate to crates.io.

[sfackler]

Ah, it's probably coming in through libserialize

[brson]

I'm ok with this strategy.