mockersf/hocon.rs

Parse HOCON configuration files in Rust

HOCON.rs

Warning

This repository is archived as I don't use this crate anymore and don't have the time to update its dependencies. It's stuck on an old version of nom and too painful for me to update for now.

You can contact me if you want to help with maintenance or take over.

The API docs for the master branch are published here.

Parse HOCON configuration files in Rust following the HOCON Specifications.

This implementation goal is to be as permissive as possible, returning a valid document with all errors wrapped in Hocon::BadValue. strict mode can be enabled to return the first Error encountered instead.

Examples

Parsing a string to a struct using serde

use serde::Deserialize;

#[derive(Deserialize)]
struct Configuration {
    host: String,
    port: u8,
    auto_connect: bool,
}

fn main() -> Result<(), Error> {
    let s = r#"{
        host: 127.0.0.1
        port: 80
        auto_connect: false
    }"#;

    let conf: Configuration = hocon::de::from_str(s)?;

    Ok(())
}

Reading from a string and getting value directly

use hocon::HoconLoader;

fn main() -> Result<(), Error> {
    let s = r#"{ a: 7 }"#;

    let doc = HoconLoader::new()
        .load_str(s)?
        .hocon()?;

    let a = doc["a"].as_i64();
    assert_eq!(a, Some(7));

    Ok(())
}

Deserializing to a struct using serde

use serde::Deserialize;

use hocon::HoconLoader;

#[derive(Deserialize)]
struct Configuration {
    host: String,
    port: u8,
    auto_connect: bool,
}

fn main() -> Result<(), Error> {
    let s = r#"{
        host: 127.0.0.1
        port: 80
        auto_connect: false
    }"#;

    let conf: Configuration = HoconLoader::new()
        .load_str(s)?
        .resolve()?;

    Ok(())
}

Reading from a file

use hocon::HoconLoader;

fn main() -> Result<(), Error> {
    let doc = HoconLoader::new()
        .load_file("tests/data/basic.conf")?
        .hocon()?;

    let a = doc["a"].as_i64();
    assert_eq!(a, Some(5));

    Ok(())
}

Reading from several documents

use hocon::HoconLoader;

fn main() -> Result<(), Error> {
    let s = r#"{
        a: will be changed
        unchanged: original value
    }"#;

    let doc = HoconLoader::new()
        .load_str(s)?
        .load_file("tests/data/basic.conf")?
        .hocon()?;

    let a = doc["a"].as_i64();
    assert_eq!(a, Some(5));
    let unchanged = doc["unchanged"].as_string();
    assert_eq!(unchanged, Some(String::from("original value")));

    Ok(())
}

Features

All features are enabled by default. They can be disabled to reduce dependencies.

url-support

This feature enable fetching URLs in includes with include url("http://mydomain.com/myfile.conf") (see spec). If disabled, includes will only load local files specified with include "path/to/file.conf" or include file("path/to/file.conf").

serde-support

This feature enable deserializing to a struct implementing Deserialize using serde

use serde::Deserialize;

use hocon::HoconLoader;

#[derive(Deserialize)]
struct Configuration {
    host: String,
    port: u8,
    auto_connect: bool,
}

# fn main() -> Result<(), Error> {
let s = r#"{host: 127.0.0.1, port: 80, auto_connect: false}"#;

# #[cfg(feature = "serde-support")]
let conf: Configuration = HoconLoader::new().load_str(s)?.resolve()?;
# Ok(())
# }

Spec Coverage

https://github.com/lightbend/config/blob/master/HOCON.md

• parsing JSON
• comments
• omit root braces
• key-value separator
• commas are optional if newline is present
• whitespace
• duplicate keys and object merging
• unquoted strings
• multi-line strings
• value concatenation
• object concatenation
• array concatenation
• path expressions
• path as keys
• substitutions
• includes
• conversion of numerically-indexed objects to arrays
• allow URL for included files
• duration unit format
• period unit format
• size unit format

hocon.rs's Issues

panic when using the `=+` field separator on. an array that was substituted

the following document:

{
    "array1": [1],
    "v": ${array1}
    "v" += 2
}

panics:

RUST_BACKTRACE=1 cargo run --example hocon2json -- tests/data/error.conf
    Finished dev [unoptimized + debuginfo] target(s) in 0.16s
     Running `target/debug/examples/hocon2json tests/data/basic.conf`
thread 'main' panicked at 'index 2 out of range for slice of length 1', src/internals/internal.rs:377:45
stack backtrace:
   0: <std::sys_common::backtrace::_print::DisplayBacktrace as core::fmt::Display>::fmt
             at /Users/francois/.rustup/toolchains/stable-x86_64-apple-darwin/lib/rustlib/src/rust/src/libstd/panicking.rs:0
   1: core::fmt::write
             at /Users/francois/.rustup/toolchains/stable-x86_64-apple-darwin/lib/rustlib/src/rust/src/libstd/panicking.rs:0
   2: std::io::Write::write_fmt
             at /Users/francois/.rustup/toolchains/stable-x86_64-apple-darwin/lib/rustlib/src/rust/src/libstd/panicking.rs:0
   3: std::panicking::default_hook::{{closure}}
             at /Users/francois/.rustup/toolchains/stable-x86_64-apple-darwin/lib/rustlib/src/rust/src/libstd/panicking.rs:0
   4: std::panicking::default_hook
             at /Users/francois/.rustup/toolchains/stable-x86_64-apple-darwin/lib/rustlib/src/rust/src/libstd/panicking.rs:0
   5: std::panicking::rust_panic_with_hook
             at /Users/francois/.rustup/toolchains/stable-x86_64-apple-darwin/lib/rustlib/src/rust/src/libstd/panicking.rs:0
   6: rust_begin_unwind
             at /Users/francois/.rustup/toolchains/stable-x86_64-apple-darwin/lib/rustlib/src/rust/src/libstd/panicking.rs:0
   7: core::panicking::panic_fmt
             at src/libcore/panicking.rs:101
   8: core::slice::slice_index_len_fail
             at src/libcore/slice/mod.rs:2751
   9: <core::ops::range::Range<usize> as core::slice::SliceIndex<[T]>>::index
             at /Users/francois/.rustup/toolchains/stable-x86_64-apple-darwin/lib/rustlib/src/rust/src/libcore/slice/mod.rs:2919
  10: core::slice::<impl core::ops::index::Index<I> for [T]>::index
             at /Users/francois/.rustup/toolchains/stable-x86_64-apple-darwin/lib/rustlib/src/rust/src/libcore/slice/mod.rs:2732
  11: <alloc::vec::Vec<T> as core::ops::index::Index<I>>::index
             at /Users/francois/.rustup/toolchains/stable-x86_64-apple-darwin/lib/rustlib/src/rust/src/liballoc/vec.rs:1942
  12: hocon::internals::internal::HoconInternal::merge
             at src/internals/internal.rs:377
  13: hocon::HoconLoader::hocon
             at src/lib.rs:452
  14: hocon2json::parse_to_json
             at examples/hocon2json.rs:33
  15: hocon2json::main
             at examples/hocon2json.rs:43
  16: std::rt::lang_start::{{closure}}
             at /Users/francois/.rustup/toolchains/stable-x86_64-apple-darwin/lib/rustlib/src/rust/src/libstd/rt.rs:67
  17: std::rt::lang_start_internal
             at /Users/francois/.rustup/toolchains/stable-x86_64-apple-darwin/lib/rustlib/src/rust/src/libstd/panicking.rs:0
  18: std::rt::lang_start
             at /Users/francois/.rustup/toolchains/stable-x86_64-apple-darwin/lib/rustlib/src/rust/src/libstd/rt.rs:67
  19: main
note: Some details are omitted, run with `RUST_BACKTRACE=full` for a verbose backtrace.

"file could not be parsed completely" with trailing CRLF newline

The following snippet tries to load the document {a:7} with a trailing CRLF newline (windows-style line endings), but panics with: failed to load: Deserialization { message: "file could not be parsed completely" }

use hocon::HoconLoader;

fn main() {
    let mut loader = HoconLoader::new().strict();
    let src = "{ a: 7 }\r\n";
    loader.load_str(src).expect("failed to load");
}

At a glance, it seems that the nom parser uses nom::newline, which only recognizes \n. Maybe nom::line_ending would fix that as a drop-in replacement?

Also, I'm not sure that this is a bug: maybe the HOCON spec simply does not allow non-LF line endings? The spec did not seem entirely clear to me on that point.

Panic when loading hocon document, for entering unreachable code

src/main.rs

use hocon::HoconLoader;

fn main() -> Result<(), Box<dyn std::error::Error>> {
    let doc = HoconLoader::new()
        .load_file(
            "/path/to/my/hocon.conf",
        )?
        .hocon()?;
    println!("{:?}", doc["DefaultParsers"]);
    Ok(())
}

Panics when it loads the document (run in release mode, as debug mode doesn't seem to ever finish loading):

thread 'main' panicked at 'internal error: entered unreachable code', /Users/alexhunt/.cargo/registry/src/github.com-1ecc6299db9ec823/hocon-0.3.5/src/internals/value.rs:332:18
stack backtrace:
   0: <std::sys_common::backtrace::_print::DisplayBacktrace as core::fmt::Display>::fmt
   1: core::fmt::write
   2: std::io::Write::write_fmt
   3: std::panicking::default_hook::{{closure}}
   4: std::panicking::default_hook
   5: std::panicking::rust_panic_with_hook
   6: std::panicking::begin_panic
   7: core::hash::impls::<impl core::hash::Hash for [T]>::hash
   8: hashbrown::map::make_hash
   9: hashbrown::rustc_entry::<impl hashbrown::map::HashMap<K,V,S>>::rustc_entry
  10: hocon::internals::internal::HoconInternal::merge
  11: hocon::HoconLoader::hocon
  12: ironlime::main
  13: std::rt::lang_start::{{closure}}
  14: std::rt::lang_start_internal
  15: main

I unfortunately cannot give you the document(s) that cause this, as they are proprietary. I also do not have a minimum working example, as I have no idea what triggers it yet. The file being loaded includes many other files, and exercises many hocon features. In total, it's almost 100,000 lines of hocon, so it may take me a while to find a minimum reproducible example.

It seems to be hitting the unreachable() in src/internals/value.rs:

impl std::hash::Hash for HoconValue {
    fn hash<H>(&self, state: &mut H)
    where
        H: std::hash::Hasher,
    {
        match self {
            HoconValue::Integer(i) => i.hash(state),
            HoconValue::String(s) => s.hash(state),
            _ => unreachable!(),
        };
    }
}

Tested with hocon v0.3.5

Environment variable overrides are not supported

a = 5
a = ${?X}

If the environment variable X=10 is configured, the expected result is 10, and if every configuration is configured, the expected result is 5.

But now if X is not set, the return result is None.

Losing `.0` (dot zero) in unquoted strings

With Typesafe Config (authors of HOCON):

println(
  ConfigFactory
    .parseString("a = 1.0.1-zxc")
    .getString("a")
)

Prints 1.0.1-zxc.

With hocon.rs 0.9.0:

fn main() {
    let mut loader = hocon::HoconLoader::new().strict();
    loader = loader.load_str("a = 1.0.1-zxc").unwrap();
    let parsed = loader.hocon().unwrap();
    println!("{}", parsed["a"].as_string().unwrap());
}

Prints 1.1-zxc, losing the .0 that was in the original string.

I understand there is a chance that the reference HOCON implementation by Typesafe could be wrong. Or is it perhaps a bug in hocon.rs?

Remove failure-crate in favor of thiserror-crate

The thiserror crate provides convenient derive-macro for std::error::Error

This would remove any additional error dependency (failure) for hocon-library users.
I would be willing to provide a PR in case there is interest to go this route.

null without a comma at the end is Hocon::String("null"), not Hocon::null

Hello,
First of all, Thank You very much for implementing HOCON for rust!

There seem to be a following anomaly with null-values: If there isn't a comma after null value, it's interpreted as Hocon::String("null"), instead of Hocon::Null. By specification both cases should be null. This is also how Config does it (both are nulls), so this seems to be a bug.

use hocon::{Hocon, HoconLoader, Error};

fn check_null(doc: &Hocon) {
   match doc {
        Hocon::Null => {
            println!("It's null!");
        }
        _ => {
            println!("{:#?}", doc);
            panic!();
        }
   }
}

fn main() -> Result<(), Error> {
    // this works
    //let example = r#"{ null_with_comma = null, a { a_null = null, } }"#;
    let example   = r#"{ null_with_comma = null, a { a_null = null  } }"#;

    let doc = HoconLoader::new().load_str(example)?.hocon()?;

    check_null(&doc["null_with_comma"]);

    check_null(&doc["a"]["a_null"]);
    Ok(())
}

I'm planning to use hocon.rs for one project and noticed this while preparing an RFC pull request for hocon.rs. I will open the RFC pull request soon, so we can discuss about it separately.

Issue with tagged enum

Parsing of tagged enum doesn't seem to work properly.

I have following definitions:

#[derive(Clone, Debug, Deserialize, PartialEq, Eq, Hash)]
#[serde(rename_all = "camelCase")]
pub struct RequestOptions {
    #[serde(default)]
    #[serde(with = "humantime_serde")]
    timeout:      Option<Duration>,
    retry_policy: Option<RetryPolicy>,
}

#[derive(Clone, Debug, Deserialize, PartialEq, Eq, Hash)]
#[serde(tag = "type")]
#[serde(rename_all = "camelCase")]
pub enum RetryPolicy {
    None,
    #[serde(rename = "camelCase")]
    Asap {
        num_retries: u32,
    },
}

Parsing sample input does not recognizes variant:

let s = r#"
retryPolicy {
     type: asap
     numRetries: 2
 }
"#;
let config: RequestOptions = HoconLoader::new().load_str(s).unwrap().resolve().unwrap();

Above code panics.

size unit format deserialize by Serde error

use hocon::HoconLoader;
use serde::Deserialize;

#[derive(Deserialize)]
struct Test {
    data: f64,
}
fn main() -> anyhow::Result<()> {
    let s = r#"{
        data: 32M
    }"#;

    //let doc = HoconLoader::new().load_str(s)?.hocon()?;
    //let s = doc["data"].as_bytes().unwrap();
    //println!("{}", s); //this is ok

    let conf: Test = HoconLoader::new().load_str(s)?.resolve()?;
    println!("{:?}", conf.data);
    Ok(())
}

It outputs: Error: Error deserializing: "data: Invalid type for field \"data\", expected float"

and as_bytes():Option<f64> should be as_bytes():Option<u64>?

Extra-ASCII characters in unquoted strings errors out

This function works as expected.

fn main() {
    let thing = r#"a = "sˢ""#;
    let loader = hocon::HoconLoader::new()
        .load_str(thing).unwrap();
    let parsed = loader.hocon().unwrap();
    println!("{}", parsed["a"].as_string().unwrap());

}

However, removing the quotes around sˢ will cause the parser to fail.

My reading of the HOCON spec tells me that ˢ and similar letters should be allowed to show up unquoted. In addition, pyhocon accepts such characters unquoted, so it seems to me that this is permissible.

load_file doesnt fail with non-existent file

I can pass a &Path with total bogus to HoconLoader::load_file and not get a IOError. Instead, an empty Hocon struct is returned as it seems

Of course I can check this on my application but I wonder if this was intentional in order to merge multiple dynamic hocon files or just a bug.

Cargo.toml documentation URL is incorrect

the link on crates.io doesn't work; should probably be this:

documentation = "https://docs.rs/hocon"

Provide path for each Hocon node

It would be great if a Hocon node could also yield its current path in the document.

It should merely be a additional field in the Hocon-enum, though I could be missing some complexity since I currently have no idea how this nom parser macros work and I assume you need the information from there.

load_file should use a Path type for the path

Something like this preserves the ergonomics of passing in a string while also working with file names that are not representable as UTF-8, which is possible on the majority of posix systems, as well as on windows systems:

pub fn load_file<P: AsRef<Path>>(&self, path: P) -> Result<Self, Error> {
        let mut file_path = path.as_ref().to_path_buf();

Failure parsing file with CRLF line endings

I tried parsing a simple document with HoconLoader::new().load_str(string):

{
    aaa {
        bbb = "ccc"
    }
}

It failed with Error::Parse.

While trying to debug it, it turns out that the same config parses fine when loaded using r#{ ... }"# string.

I hexdumped both strings.

file:

0 |7b0d0a20 20202061 6161207b 0d0a2020| {..    aaa {..   00000000
1 |20202020 20206262 62203d20 22636363|       bbb = "ccc 00000010
2 |220d0a20 2020207d 0d0a7d0d 0a|       "..    }..}..    00000020

string:

0 |7b0a2020 20206161 61207b0a 20202020| {.    aaa {.     00000000
1 |20202020 62626220 3d202263 6363220a|     bbb = "ccc". 00000010
2 |20202020 7d0a7d0a|                       }.}.         00000020

The string failing parsing has CRLF (0d0a) line endings. The string parsing fine has LF (0a) line endings.

How can I deserialize an enum in struct？

#[derive(Debug,Deserialize)]
enum RoleType {
    Admin,
    User,
    VipUser,
}

#[derive(Debug, Deserialize)]
struct User {
    name: String,
    age: u8,
    weight: u8,
    high: f32,
 #[serde(flatten)]
    role_type:RoleType
}


#[test]
fn test01() {
    let s = r#"{
        name="yancheng"
        age=28
        weight=76
        high=1.77
        role_type="VipUser"
    }"#;

    let user: User = hocon::de::from_str(s).unwrap();

    println!("{:?}", user)
}

called `Result::unwrap()` on an `Err` value: Deserialization { message: ".: no variant of enum RoleType found in flattened data" }
thread 'test01' panicked at 'called `Result::unwrap()` on an `Err` value: Deserialization { message: ".: no variant of enum RoleType found in flattened data" }', examples\hocon_test01.rs:50:45
stack backtrace:

Error deserializing: missing field when chaining load_file&resolve

I'm trying to use the following code to load a config:

    let tmp_conf: TestConfig = HoconLoader::new()
        .load_file("./tmp.conf")?
        .resolve()?;

But I get the following error: Error deserializing: ".: missing field `child2`"

Here is the config file:

title = "test"

child1 {
  home = "./dir1"
}

child2 {
  home = "./dir2"
}

Here are the defined structs:

#[derive(Clone, Deserialize)]
pub struct TestConfig {
    pub title: String,
    pub child1: Child1,
    pub child2: Child2
}

#[derive(Clone, Deserialize)]
pub struct Child1 {
    pub home: String,
}

#[derive(Clone, Deserialize)]
pub struct Child2 {
    pub home: String,
}

Important note, using from_str directly works without error:

 let s = r#"{
      title = "test"
      
      child1 {
        home = "./dir1"
      }
      
      child2 {
        home = "./dir2"
      }
    }"#;

let config: TestConfig = hocon::de::from_str(s)?;

`HoconLoader.load_file` always loads empty object

When loading a file using HoconLoader's load_file, the parsed object is always empty.

When reading the same file using fs::read_to_string and then loading it with HoconLoader.load_str works as expected.

Sample code:

println!(
    "{:?}",
    HoconLoader::new()
        .load_file(&path)
        .unwrap()
        .hocon()
        .unwrap(),
);

Expected output

Parsed contents of the file located at path

Actual output

Hash({}) regardless of the actual contents of the file at path

Repository

https://gitlab.com/frantisekhanzlikbl/hocon.rs-issue-25

Versions:

component	version
hocon	0.3.4
cargo	cargo 1.45.0-nightly (40ebd5220 2020-06-01)
rustc	rustc 1.46.0-nightly (feb3536eb 2020-06-09)

Auto-unescape strings and handle unicode escape sequences in strings

Currently the parser doesn't auto-unescape strings (e.g. "\\" gets parsed to: r#"\\"# when it should actually be parsed to: r#"\"#).

Same regarding unicode escape sequences, e.g.: "\uD834".

There's an example here that is able to properly validate unicode escape sequences: https://github.com/changhe3/nom-json-parser/blob/cce34f560f394cdf1601ab9c5c2fd012eb405084/src/parser.rs#L132 but it doesn't do any auto-unescaping.

Expose full path information when missing field when deserializing using serde

Currently, when there is missing field when deserializing using serde, I get error
Error deserializing: missing field `endpoint`"

I would be happy if I could get full path of an error (e.g. a_service.endpoint).

I can see two solutions:

1. exposing crate::serde::de::Deserializer so I could use serde_path_to_error crate
2. using this serde_path_to_error crate internally.

Would any of these two solutions be possible?

serde deserializer fails for structs using `serde(default)`

#[test]
fn hocon_and_serde_default() {
    #[derive(Deserialize, Debug)]
    struct MyStruct {
        #[serde(default)]
        size: f64,
    }

    let s: MyStruct = hocon::HoconLoader::new()
        .load_str("")
        .unwrap()
        .resolve()
        .unwrap();
    eprintln!("s: {:?}", s);
}

yields:

failures:

---- config::hocon_and_serde_default stdout ----
thread 'config::hocon_and_serde_default' panicked at 'called `Result::unwrap()` on an `Err` value: Deserialization { message: "missing float for
field String(\"size\")" }', src/libcore/result.rs:1165:5
note: run with `RUST_BACKTRACE=1` environment variable to display a backtrace.


failures:
    config::hocon_and_serde_default

What should happen is the serde machinery will compute a default value and that should be used instead of generating an error.

`+=` results in weird object tree

This works and produces an array containing a single object with 4 keys:

keys [{
  key: "1",
  mods: "CTRL|ALT",
  action: "ActivateTab",
  arg: "0"
}]

but this yields a weird resultant object which subsequently fails to deserialize when using this workaround

keys += [{
  key: "1",
  mods: "CTRL|ALT",
  action: "ActivateTab",
  arg: "0"
}]

yields:

  "keys": [
    [
      {
        "key": "1"
      }
    ],
    [
      {
        "mods": "CTRL|ALT"
      }
    ],
    [
      {
        "action": "ActivateTab"
      }
    ],
    [
      {
        "arg": "0"
      }
    ]
  ],

I'm new to hocon, but I would expect both of these inputs to have the same outputs.

Included substitution is inconsistent with Typesafe Config

Per https://github.com/lightbend/config/blob/main/HOCON.md#includes :

Recall that substitution happens as a final step, after parsing. It should be done for the entire app's configuration, not for single files in isolation. Therefore, if an included file contains substitutions, they must be "fixed up" to be relative to the app's configuration root.

Maybe it's not 100% clear how this should be interpreted, but if we take these files:

main.conf:

include "included"

a = main

included.conf:

a = included
b = ${a}

And load main.conf, then Typesafe Config produces:

{
  "a": "main",
  "b": "main"
}

But hocon-rs 0.9.0:

{
  "a": "main",
  "b": "included"
}

hocon-rs sets b to main only if main.conf explicitly duplicates the assignment:

include "included"

a = main
b = ${a}

but that defeats the purpose of including files with default values.

std::time::Duration is an invalid type for "1 second"

Hi, I'm using hocon 0.4.0 and serde 1.0.124. The config file says blah = 1 second, the config struct says blah: std::time::Duration, and hocon says

Error: Error deserializing: "blah: invalid type for field \"blah\""

When I change the struct's field type from std::time::Duration to String, then the struct field successfully gets the textual value 1 second.

Am I doing something wrong please? I looked into Hocon's source code and it looks like std::time::Duration is supported.

PS. Hocon is the best config format ever, loved it since Scala times, thanks for your work.

Support for 'dashed' property names

Hi, thanks for this project.

I am trying to migrate a project from Scala to Rust and keep the config for backwards compatibility with the automation. I was hoping to be able read our config, which uses dashes to separate words, instead of underlines. Is there a way to accomplish this? I didn't see any configuration knobs.

Example config:

  concurrency: {
    server-threads: 16
    client-threads: 8
    foo-bar: {
       nested-config: true
    }
  }

Overly permissive?

Here's a little example:

#[derive(Deserialize, Default)]
struct Foo {
  #[serde(default)]
  foo: bool,
}

with this invalid input file:

foo: "

when loaded with:

  let file = match hocon::HoconLoader::new().strict().load_file(p) {
      Err(err) => bail!("Error opening {}: {}", p.display(), err),
      Ok(file) => file,
  };
  let cfg: Self = file
       .resolve()
       .map_err(|e| format_err!("Error parsing HOCON from {}: {}", p.display(), e))?;

The cfg ends up with the default values for the fields rather than reporting any errors.

Is this expected behavior?

Remove dependency on Openssl

hocon.rs has a dependency on reqwest which by default depends on native-tls which again depends on openssl, which has a c dependency and requires additional header-files on the system.

cargo tree -i -p native-tls
native-tls v0.2.8
├── hyper-tls v0.5.0
│   └── reqwest v0.11.0
│       └── hocon v0.5.3-dev (/home/marc/Development/projects/hocon.rs)
├── reqwest v0.11.0 (*)
└── tokio-native-tls v0.3.0
    ├── hyper-tls v0.5.0 (*)
    └── reqwest v0.11.0 (*)

reqwest allows to disable native-tls and instead use rustls.