Deprecate the in-tree url crate

[brson]

Users should use the cargo-ified https://github.com/servo/rust-url.

Deprecate for a release or two then delete.

cc @SimonSapin

[SimonSapin]

👍

[SimonSapin]

Related: #10707

[SimonSapin]

I tried this:

diff --git a/src/liburl/lib.rs b/src/liburl/lib.rs
index b95fc3c..548ef46 100644
--- a/src/liburl/lib.rs
+++ b/src/liburl/lib.rs
@@ -21,6 +21,8 @@
        html_playground_url = "http://play.rust-lang.org/")]
 #![feature(default_type_params)]

+#![deprecated="This is being removed. Use rust-url instead. https://github.com/servo/rust-url"]
+
 use std::collections::HashMap;
 use std::fmt;
 use std::from_str::FromStr;

Hoping to deprecate the whole crate, but then building this program does not emit any warning:

extern crate url;
use url::Url;

fn main() {
    Url::parse("").unwrap();
}

I expected a deprecation warning on the extern crate line. Is there another way to achieve this, or do I need to annotate individual items in the crate?

[alexcrichton]

That should have worked, but you may need to remove the #![experimental] annotation above (they may be conflicting).

I would also personally find it very helpful to annotate methods in particular what the path forward is (or just a general post about how to migrate).

[SimonSapin]

Removing #![experimental] worked, thanks.

Should this deprecation go through the RFC process, or can I assume that the team wants it since @brson filed this issue?

The documentation at http://servo.github.io/rust-url/ explains how to use rust-url, and in particular the concept of relative v.s. non-relative URL schemes (e.g. http vs data) which is a bit unusual. I believe this sufficient to make migration straightforward, but I’m obviously biased. Any feedback on the documentation is welcome. (I’ll make the deprecation message include the documentation’s URL, it seems more useful landing page than the github repo.)

[alexcrichton]

Having an issue is sometimes considered a "todo item" rather than "everyone has approved this", you'll find both styles of issues on the issue tracker. We don't have much precedent for deprecating an in-tree crate, so we're forging new territory here.

I'd like to start moving crates out of the repo, however, so I hope to have some more on this topic soon.