use ring on Linux; native-tls on other platforms
Python wheels on Linux require statically linked SSL libraries.
We were previously relying on the native-tls-vendored feature in
reqwest, but that does not work with Bazel, as openssl-src makes
assumptions that break when sandboxed. The static libs distributed
by distros like Ubuntu fail to link, and while we could potentially
build OpenSSL ourselves, we'd then need to keep it up to
date.
On Windows and Mac however, native-tls is preferable to ring, as it
allows us to get free updates from the OS, and results in
a smaller library.
Rust currently only supports platform-specific features in nightly,
and cargo-raze does not have support for them, so we currently need
to override the generated build file with a hand-crafted one that
specifies the relative features/deps for each platform.
update.py has been updated to automatically keep the version numbers
in this file up to date, so it should hopefully not prove too hard to
maintain going forward.
2020-11-15 06:24:05 +01:00
|
|
|
"""
|
|
|
|
|
We currently need to manually maintain this file, so we can use
|
|
|
|
|
ring on Linux, and native-tls on other platforms. We use ring on
|
|
|
|
|
Linux because the wheels need the SSL library statically linked in,
|
|
|
|
|
and native-tls-vendored is broken in Bazel due to sandboxing. We
|
|
|
|
|
prefer native-tls on other platforms because it reduces the resulting
|
|
|
|
|
binary size, and we get free updates from the OS.
|
|
|
|
|
|
|
|
|
|
Building openssl statically ourselves and linking it in would be
|
|
|
|
|
another valid solution, but we would need to ensure we keep it up
|
|
|
|
|
to date.
|
|
|
|
|
|
|
|
|
|
update.py takes care of keeping the referenced versions
|
|
|
|
|
up to date for us.
|
|
|
|
|
"""
|
|
|
|
|
|
|
|
|
|
# buildifier: disable=load
|
|
|
|
|
load(
|
|
|
|
|
"@io_bazel_rules_rust//rust:rust.bzl",
|
|
|
|
|
"rust_binary",
|
|
|
|
|
"rust_library",
|
|
|
|
|
"rust_test",
|
|
|
|
|
)
|
|
|
|
|
|
|
|
|
|
# buildifier: disable=load
|
|
|
|
|
load("@bazel_skylib//lib:selects.bzl", "selects")
|
|
|
|
|
|
|
|
|
|
package(default_visibility = [
|
|
|
|
|
# Public for visibility by "@raze__crate__version//" targets.
|
|
|
|
|
#
|
|
|
|
|
# Prefer access through "//cargo", which limits external
|
|
|
|
|
# visibility to explicit Cargo.toml dependencies.
|
|
|
|
|
"//visibility:public",
|
|
|
|
|
])
|
|
|
|
|
|
|
|
|
|
licenses([
|
|
|
|
|
"notice", # MIT from expression "MIT OR Apache-2.0"
|
|
|
|
|
])
|
|
|
|
|
|
|
|
|
|
# Generated Targets
|
|
|
|
|
|
|
|
|
|
# Unsupported target "blocking" with type "example" omitted
|
|
|
|
|
|
|
|
|
|
# Unsupported target "form" with type "example" omitted
|
|
|
|
|
|
|
|
|
|
# Unsupported target "json_dynamic" with type "example" omitted
|
|
|
|
|
|
|
|
|
|
# Unsupported target "json_typed" with type "example" omitted
|
|
|
|
|
|
|
|
|
|
# Unsupported target "simple" with type "example" omitted
|
|
|
|
|
|
|
|
|
|
# Unsupported target "tor_socks" with type "example" omitted
|
|
|
|
|
|
|
|
|
|
rust_library(
|
|
|
|
|
name = "reqwest",
|
|
|
|
|
srcs = glob(["**/*.rs"]),
|
|
|
|
|
aliases = selects.with_or({
|
|
|
|
|
# ring on Linux
|
|
|
|
|
(
|
2020-12-30 11:39:27 +01:00
|
|
|
"@io_bazel_rules_rust//rust/platform:aarch64-unknown-linux-gnu",
|
use ring on Linux; native-tls on other platforms
Python wheels on Linux require statically linked SSL libraries.
We were previously relying on the native-tls-vendored feature in
reqwest, but that does not work with Bazel, as openssl-src makes
assumptions that break when sandboxed. The static libs distributed
by distros like Ubuntu fail to link, and while we could potentially
build OpenSSL ourselves, we'd then need to keep it up to
date.
On Windows and Mac however, native-tls is preferable to ring, as it
allows us to get free updates from the OS, and results in
a smaller library.
Rust currently only supports platform-specific features in nightly,
and cargo-raze does not have support for them, so we currently need
to override the generated build file with a hand-crafted one that
specifies the relative features/deps for each platform.
update.py has been updated to automatically keep the version numbers
in this file up to date, so it should hopefully not prove too hard to
maintain going forward.
2020-11-15 06:24:05 +01:00
|
|
|
"@io_bazel_rules_rust//rust/platform:x86_64-unknown-linux-gnu",
|
|
|
|
|
): {},
|
|
|
|
|
"//conditions:default": {
|
|
|
|
|
# native-tls
|
2020-12-30 04:33:16 +01:00
|
|
|
"@raze__native_tls__0_2_7//:native_tls": "native_tls_crate",
|
use ring on Linux; native-tls on other platforms
Python wheels on Linux require statically linked SSL libraries.
We were previously relying on the native-tls-vendored feature in
reqwest, but that does not work with Bazel, as openssl-src makes
assumptions that break when sandboxed. The static libs distributed
by distros like Ubuntu fail to link, and while we could potentially
build OpenSSL ourselves, we'd then need to keep it up to
date.
On Windows and Mac however, native-tls is preferable to ring, as it
allows us to get free updates from the OS, and results in
a smaller library.
Rust currently only supports platform-specific features in nightly,
and cargo-raze does not have support for them, so we currently need
to override the generated build file with a hand-crafted one that
specifies the relative features/deps for each platform.
update.py has been updated to automatically keep the version numbers
in this file up to date, so it should hopefully not prove too hard to
maintain going forward.
2020-11-15 06:24:05 +01:00
|
|
|
},
|
|
|
|
|
}),
|
|
|
|
|
crate_features = [
|
|
|
|
|
"__tls",
|
|
|
|
|
"json",
|
|
|
|
|
"serde_json",
|
|
|
|
|
"socks",
|
|
|
|
|
"stream",
|
|
|
|
|
"tokio-socks",
|
|
|
|
|
] + selects.with_or({
|
|
|
|
|
# ring on Linux
|
|
|
|
|
(
|
2020-12-30 11:39:27 +01:00
|
|
|
"@io_bazel_rules_rust//rust/platform:aarch64-unknown-linux-gnu",
|
use ring on Linux; native-tls on other platforms
Python wheels on Linux require statically linked SSL libraries.
We were previously relying on the native-tls-vendored feature in
reqwest, but that does not work with Bazel, as openssl-src makes
assumptions that break when sandboxed. The static libs distributed
by distros like Ubuntu fail to link, and while we could potentially
build OpenSSL ourselves, we'd then need to keep it up to
date.
On Windows and Mac however, native-tls is preferable to ring, as it
allows us to get free updates from the OS, and results in
a smaller library.
Rust currently only supports platform-specific features in nightly,
and cargo-raze does not have support for them, so we currently need
to override the generated build file with a hand-crafted one that
specifies the relative features/deps for each platform.
update.py has been updated to automatically keep the version numbers
in this file up to date, so it should hopefully not prove too hard to
maintain going forward.
2020-11-15 06:24:05 +01:00
|
|
|
"@io_bazel_rules_rust//rust/platform:x86_64-unknown-linux-gnu",
|
|
|
|
|
): [
|
|
|
|
|
"__rustls",
|
|
|
|
|
"hyper-rustls",
|
|
|
|
|
"rustls",
|
|
|
|
|
"rustls-tls",
|
|
|
|
|
"rustls-tls-webpki-roots",
|
|
|
|
|
"tokio-rustls",
|
|
|
|
|
"webpki-roots",
|
|
|
|
|
],
|
|
|
|
|
# native-tls on other platforms
|
|
|
|
|
"//conditions:default": [
|
|
|
|
|
"default-tls",
|
|
|
|
|
"hyper-tls",
|
|
|
|
|
"native-tls",
|
|
|
|
|
"native-tls-crate",
|
|
|
|
|
"tokio-tls",
|
|
|
|
|
],
|
|
|
|
|
}),
|
|
|
|
|
crate_root = "src/lib.rs",
|
|
|
|
|
crate_type = "lib",
|
|
|
|
|
edition = "2018",
|
|
|
|
|
rustc_flags = [
|
|
|
|
|
"--cap-lints=allow",
|
|
|
|
|
],
|
|
|
|
|
tags = [
|
|
|
|
|
"cargo-raze",
|
|
|
|
|
"manual",
|
|
|
|
|
],
|
|
|
|
|
version = "0.10.8",
|
|
|
|
|
# buildifier: leave-alone
|
|
|
|
|
deps = [
|
|
|
|
|
"@raze__bytes__0_5_6//:bytes",
|
2021-02-03 11:29:48 +01:00
|
|
|
"@raze__http__0_2_3//:http",
|
use ring on Linux; native-tls on other platforms
Python wheels on Linux require statically linked SSL libraries.
We were previously relying on the native-tls-vendored feature in
reqwest, but that does not work with Bazel, as openssl-src makes
assumptions that break when sandboxed. The static libs distributed
by distros like Ubuntu fail to link, and while we could potentially
build OpenSSL ourselves, we'd then need to keep it up to
date.
On Windows and Mac however, native-tls is preferable to ring, as it
allows us to get free updates from the OS, and results in
a smaller library.
Rust currently only supports platform-specific features in nightly,
and cargo-raze does not have support for them, so we currently need
to override the generated build file with a hand-crafted one that
specifies the relative features/deps for each platform.
update.py has been updated to automatically keep the version numbers
in this file up to date, so it should hopefully not prove too hard to
maintain going forward.
2020-11-15 06:24:05 +01:00
|
|
|
"@raze__hyper_timeout__0_3_1//:hyper_timeout",
|
|
|
|
|
"@raze__mime_guess__2_0_3//:mime_guess",
|
2021-03-07 10:04:34 +01:00
|
|
|
"@raze__serde__1_0_124//:serde",
|
|
|
|
|
"@raze__serde_json__1_0_64//:serde_json",
|
use ring on Linux; native-tls on other platforms
Python wheels on Linux require statically linked SSL libraries.
We were previously relying on the native-tls-vendored feature in
reqwest, but that does not work with Bazel, as openssl-src makes
assumptions that break when sandboxed. The static libs distributed
by distros like Ubuntu fail to link, and while we could potentially
build OpenSSL ourselves, we'd then need to keep it up to
date.
On Windows and Mac however, native-tls is preferable to ring, as it
allows us to get free updates from the OS, and results in
a smaller library.
Rust currently only supports platform-specific features in nightly,
and cargo-raze does not have support for them, so we currently need
to override the generated build file with a hand-crafted one that
specifies the relative features/deps for each platform.
update.py has been updated to automatically keep the version numbers
in this file up to date, so it should hopefully not prove too hard to
maintain going forward.
2020-11-15 06:24:05 +01:00
|
|
|
"@raze__serde_urlencoded__0_6_1//:serde_urlencoded",
|
2021-03-07 10:04:34 +01:00
|
|
|
"@raze__url__2_2_1//:url",
|
use ring on Linux; native-tls on other platforms
Python wheels on Linux require statically linked SSL libraries.
We were previously relying on the native-tls-vendored feature in
reqwest, but that does not work with Bazel, as openssl-src makes
assumptions that break when sandboxed. The static libs distributed
by distros like Ubuntu fail to link, and while we could potentially
build OpenSSL ourselves, we'd then need to keep it up to
date.
On Windows and Mac however, native-tls is preferable to ring, as it
allows us to get free updates from the OS, and results in
a smaller library.
Rust currently only supports platform-specific features in nightly,
and cargo-raze does not have support for them, so we currently need
to override the generated build file with a hand-crafted one that
specifies the relative features/deps for each platform.
update.py has been updated to automatically keep the version numbers
in this file up to date, so it should hopefully not prove too hard to
maintain going forward.
2020-11-15 06:24:05 +01:00
|
|
|
] + selects.with_or({
|
|
|
|
|
# cfg(not(target_arch = "wasm32"))
|
|
|
|
|
(
|
|
|
|
|
"@io_bazel_rules_rust//rust/platform:aarch64-apple-ios",
|
2020-12-30 11:39:27 +01:00
|
|
|
"@io_bazel_rules_rust//rust/platform:aarch64-unknown-linux-gnu",
|
use ring on Linux; native-tls on other platforms
Python wheels on Linux require statically linked SSL libraries.
We were previously relying on the native-tls-vendored feature in
reqwest, but that does not work with Bazel, as openssl-src makes
assumptions that break when sandboxed. The static libs distributed
by distros like Ubuntu fail to link, and while we could potentially
build OpenSSL ourselves, we'd then need to keep it up to
date.
On Windows and Mac however, native-tls is preferable to ring, as it
allows us to get free updates from the OS, and results in
a smaller library.
Rust currently only supports platform-specific features in nightly,
and cargo-raze does not have support for them, so we currently need
to override the generated build file with a hand-crafted one that
specifies the relative features/deps for each platform.
update.py has been updated to automatically keep the version numbers
in this file up to date, so it should hopefully not prove too hard to
maintain going forward.
2020-11-15 06:24:05 +01:00
|
|
|
"@io_bazel_rules_rust//rust/platform:x86_64-apple-darwin",
|
|
|
|
|
"@io_bazel_rules_rust//rust/platform:x86_64-apple-ios",
|
|
|
|
|
"@io_bazel_rules_rust//rust/platform:x86_64-pc-windows-msvc",
|
|
|
|
|
"@io_bazel_rules_rust//rust/platform:x86_64-unknown-linux-gnu",
|
|
|
|
|
): [
|
|
|
|
|
"@raze__base64__0_13_0//:base64",
|
2021-02-06 04:42:38 +01:00
|
|
|
"@raze__encoding_rs__0_8_28//:encoding_rs",
|
2021-03-07 10:04:34 +01:00
|
|
|
"@raze__futures_core__0_3_13//:futures_core",
|
|
|
|
|
"@raze__futures_util__0_3_13//:futures_util",
|
use ring on Linux; native-tls on other platforms
Python wheels on Linux require statically linked SSL libraries.
We were previously relying on the native-tls-vendored feature in
reqwest, but that does not work with Bazel, as openssl-src makes
assumptions that break when sandboxed. The static libs distributed
by distros like Ubuntu fail to link, and while we could potentially
build OpenSSL ourselves, we'd then need to keep it up to
date.
On Windows and Mac however, native-tls is preferable to ring, as it
allows us to get free updates from the OS, and results in
a smaller library.
Rust currently only supports platform-specific features in nightly,
and cargo-raze does not have support for them, so we currently need
to override the generated build file with a hand-crafted one that
specifies the relative features/deps for each platform.
update.py has been updated to automatically keep the version numbers
in this file up to date, so it should hopefully not prove too hard to
maintain going forward.
2020-11-15 06:24:05 +01:00
|
|
|
"@raze__http_body__0_3_1//:http_body",
|
2021-02-06 04:42:38 +01:00
|
|
|
"@raze__hyper__0_13_10//:hyper",
|
use ring on Linux; native-tls on other platforms
Python wheels on Linux require statically linked SSL libraries.
We were previously relying on the native-tls-vendored feature in
reqwest, but that does not work with Bazel, as openssl-src makes
assumptions that break when sandboxed. The static libs distributed
by distros like Ubuntu fail to link, and while we could potentially
build OpenSSL ourselves, we'd then need to keep it up to
date.
On Windows and Mac however, native-tls is preferable to ring, as it
allows us to get free updates from the OS, and results in
a smaller library.
Rust currently only supports platform-specific features in nightly,
and cargo-raze does not have support for them, so we currently need
to override the generated build file with a hand-crafted one that
specifies the relative features/deps for each platform.
update.py has been updated to automatically keep the version numbers
in this file up to date, so it should hopefully not prove too hard to
maintain going forward.
2020-11-15 06:24:05 +01:00
|
|
|
"@raze__ipnet__2_3_0//:ipnet",
|
|
|
|
|
"@raze__lazy_static__1_4_0//:lazy_static",
|
2021-02-03 11:29:48 +01:00
|
|
|
"@raze__log__0_4_14//:log",
|
use ring on Linux; native-tls on other platforms
Python wheels on Linux require statically linked SSL libraries.
We were previously relying on the native-tls-vendored feature in
reqwest, but that does not work with Bazel, as openssl-src makes
assumptions that break when sandboxed. The static libs distributed
by distros like Ubuntu fail to link, and while we could potentially
build OpenSSL ourselves, we'd then need to keep it up to
date.
On Windows and Mac however, native-tls is preferable to ring, as it
allows us to get free updates from the OS, and results in
a smaller library.
Rust currently only supports platform-specific features in nightly,
and cargo-raze does not have support for them, so we currently need
to override the generated build file with a hand-crafted one that
specifies the relative features/deps for each platform.
update.py has been updated to automatically keep the version numbers
in this file up to date, so it should hopefully not prove too hard to
maintain going forward.
2020-11-15 06:24:05 +01:00
|
|
|
"@raze__mime__0_3_16//:mime",
|
|
|
|
|
"@raze__percent_encoding__2_1_0//:percent_encoding",
|
2021-03-07 10:04:34 +01:00
|
|
|
"@raze__pin_project_lite__0_1_12//:pin_project_lite",
|
2021-02-03 11:29:48 +01:00
|
|
|
"@raze__tokio__0_2_25//:tokio",
|
use ring on Linux; native-tls on other platforms
Python wheels on Linux require statically linked SSL libraries.
We were previously relying on the native-tls-vendored feature in
reqwest, but that does not work with Bazel, as openssl-src makes
assumptions that break when sandboxed. The static libs distributed
by distros like Ubuntu fail to link, and while we could potentially
build OpenSSL ourselves, we'd then need to keep it up to
date.
On Windows and Mac however, native-tls is preferable to ring, as it
allows us to get free updates from the OS, and results in
a smaller library.
Rust currently only supports platform-specific features in nightly,
and cargo-raze does not have support for them, so we currently need
to override the generated build file with a hand-crafted one that
specifies the relative features/deps for each platform.
update.py has been updated to automatically keep the version numbers
in this file up to date, so it should hopefully not prove too hard to
maintain going forward.
2020-11-15 06:24:05 +01:00
|
|
|
"@raze__tokio_socks__0_3_0//:tokio_socks",
|
|
|
|
|
],
|
|
|
|
|
"//conditions:default": [],
|
|
|
|
|
}) + selects.with_or({
|
|
|
|
|
# cfg(windows)
|
|
|
|
|
(
|
|
|
|
|
"@io_bazel_rules_rust//rust/platform:x86_64-pc-windows-msvc",
|
|
|
|
|
): [
|
|
|
|
|
"@raze__winreg__0_7_0//:winreg",
|
|
|
|
|
],
|
|
|
|
|
"//conditions:default": [],
|
|
|
|
|
}) + selects.with_or({
|
|
|
|
|
# ring on Linux
|
|
|
|
|
(
|
|
|
|
|
"@io_bazel_rules_rust//rust/platform:x86_64-unknown-linux-gnu",
|
2020-12-30 11:39:27 +01:00
|
|
|
"@io_bazel_rules_rust//rust/platform:aarch64-unknown-linux-gnu",
|
use ring on Linux; native-tls on other platforms
Python wheels on Linux require statically linked SSL libraries.
We were previously relying on the native-tls-vendored feature in
reqwest, but that does not work with Bazel, as openssl-src makes
assumptions that break when sandboxed. The static libs distributed
by distros like Ubuntu fail to link, and while we could potentially
build OpenSSL ourselves, we'd then need to keep it up to
date.
On Windows and Mac however, native-tls is preferable to ring, as it
allows us to get free updates from the OS, and results in
a smaller library.
Rust currently only supports platform-specific features in nightly,
and cargo-raze does not have support for them, so we currently need
to override the generated build file with a hand-crafted one that
specifies the relative features/deps for each platform.
update.py has been updated to automatically keep the version numbers
in this file up to date, so it should hopefully not prove too hard to
maintain going forward.
2020-11-15 06:24:05 +01:00
|
|
|
): [
|
|
|
|
|
"@raze__hyper_rustls__0_21_0//:hyper_rustls",
|
|
|
|
|
"@raze__rustls__0_18_1//:rustls",
|
|
|
|
|
"@raze__tokio_rustls__0_14_1//:tokio_rustls",
|
|
|
|
|
"@raze__webpki_roots__0_20_0//:webpki_roots",
|
|
|
|
|
],
|
|
|
|
|
# native-tls on other platforms
|
|
|
|
|
"//conditions:default": [
|
|
|
|
|
"@raze__hyper_tls__0_4_3//:hyper_tls",
|
2020-12-30 04:33:16 +01:00
|
|
|
"@raze__native_tls__0_2_7//:native_tls",
|
use ring on Linux; native-tls on other platforms
Python wheels on Linux require statically linked SSL libraries.
We were previously relying on the native-tls-vendored feature in
reqwest, but that does not work with Bazel, as openssl-src makes
assumptions that break when sandboxed. The static libs distributed
by distros like Ubuntu fail to link, and while we could potentially
build OpenSSL ourselves, we'd then need to keep it up to
date.
On Windows and Mac however, native-tls is preferable to ring, as it
allows us to get free updates from the OS, and results in
a smaller library.
Rust currently only supports platform-specific features in nightly,
and cargo-raze does not have support for them, so we currently need
to override the generated build file with a hand-crafted one that
specifies the relative features/deps for each platform.
update.py has been updated to automatically keep the version numbers
in this file up to date, so it should hopefully not prove too hard to
maintain going forward.
2020-11-15 06:24:05 +01:00
|
|
|
"@raze__tokio_tls__0_3_1//:tokio_tls",
|
|
|
|
|
],
|
|
|
|
|
}),
|
|
|
|
|
)
|
|
|
|
|
|
|
|
|
|
# Unsupported target "badssl" with type "test" omitted
|
|
|
|
|
|
|
|
|
|
# Unsupported target "blocking" with type "test" omitted
|
|
|
|
|
|
|
|
|
|
# Unsupported target "brotli" with type "test" omitted
|
|
|
|
|
|
|
|
|
|
# Unsupported target "client" with type "test" omitted
|
|
|
|
|
|
|
|
|
|
# Unsupported target "cookie" with type "test" omitted
|
|
|
|
|
|
|
|
|
|
# Unsupported target "gzip" with type "test" omitted
|
|
|
|
|
|
|
|
|
|
# Unsupported target "multipart" with type "test" omitted
|
|
|
|
|
|
|
|
|
|
# Unsupported target "proxy" with type "test" omitted
|
|
|
|
|
|
|
|
|
|
# Unsupported target "redirect" with type "test" omitted
|
|
|
|
|
|
|
|
|
|
# Unsupported target "timeouts" with type "test" omitted
|