Repository: seanmonstar/reqwest (language: rust)

Issue:
0.10.4 -> 0.10.5 upgrade has a hyper-rustls/webpki-roots incompatibility
A Cargo project with

```toml
[dependencies]
reqwest = { version = "=0.10.4", default-features = false, features = ["rustls-tls"] }
yup-oauth2 = "4.0"
```

builds fine, but changing 0.10.4 to 0.10.5 results in

```
# cargo build
    Updating crates.io index
   Compiling webpki-roots v0.19.0
   Compiling hyper-rustls v0.20.0
error: Must enable exactly one of rustls-native-certs (default) or webpki-roots with tokio-runtime! (note: use `default-features = false' in a binary crate for one or other)
  --> /home/at/.cargo/registry/src/github.com-1ecc6299db9ec823/hyper-rustls-0.20.0/src/lib.rs:30:1
   |
30 | / compile_error!(
31 | |     "Must enable exactly one of rustls-native-certs (default) or webpki-roots with tokio-runtime! (note: use `default-features = false' in a binary crate for one or other)"
32 | | );
   | |__^

error: aborting due to previous error

error: could not compile `hyper-rustls`.

To learn more, run the command again with --verbose.
```

(tested `rustc 1.43.1 (8d69840ab 2020-05-04)` and `rustc 1.45.0-nightly (a74d1862d 2020-05-14)` on NixOS)

I do not know if reqwest can or should do anything about this, I leave it up to you.


Discussion / hints:
I don't quite understand, it seems to build in its own. Is it that another dependency is requiring the other feature?
We also ran into this this morning, and had to force 0.10.4 to get our builds going through CI.

All of our direct uses of reqwest look like this:

```
reqwest = { version = "0.10", default-features = false, features = ["rustls-tls", "json"]}
```

but I haven't yet had a chance to audit other dependencies to see which of them are requesting which features.
i'm seeing this failure too with this dependency line:

```
reqwest = { version = "0.10.5", default-features = false, features = ["blocking", "rustls-tls"] }
```

can we put the choice of cert source behind features, so we could choose?
We can try to publish a new version today reverting whatever change we did. At the same time, wherever this feature conflict is, it'd be good to file an issue there. Features are meant to be additive, for exactly this situation.
For us, I've boiled it down to

```toml
[package]
name = "z-2020-05-29-check-dependencies"
version = "0.1.0"
edition = "2018"

[dependencies]
reqwest = { version = "=0.10.5", default-features = false, features = ["rustls-tls", "json"]}
rusoto_core = {version = "0.43.0", default_features = false, features=["rustls"]}
```

rusoto_core uses hyper-rustls with the default features. https://github.com/rusoto/rusoto/blob/master/rusoto/core/Cargo.toml#L35

hyper-rustls with default feature enables `rustls-native-certs`; reqwest@0.10.5 enables `webpki-roots`; and that's where the conflict is.

It looks like prior to #862, reqwest didn't care which features of hyper-rustls were enabled, and after that reqwest specifically wants the webpki feature. But nothing in that pull request started depending on the existence of webpki. I wonder if we could avoid requesting any hyper-rustls features?

Fix patch:
diff --git a/Cargo.toml b/Cargo.toml
index a782eda94..507715338 100644
--- a/Cargo.toml
+++ b/Cargo.toml
@@ -95,7 +95,7 @@ native-tls-crate = { version = "0.2", optional = true, package = "native-tls" }
 tokio-tls = { version = "0.3.0", optional = true }
 
 # rustls-tls
-hyper-rustls = { version = "0.20", default-features = false, features = ["webpki-tokio"], optional = true }
+hyper-rustls = { version = "0.20", default-features = false, optional = true }
 rustls = { version = "0.17", features = ["dangerous_configuration"], optional = true }
 tokio-rustls = { version = "0.13", optional = true }
 webpki-roots = { version = "0.19", optional = true }


Test patch: