Runtime/Reactor Question

[webern]

I have the following:

Cargo.toml

[package]
name = "kube-tokio"
version = "0.1.0"
edition = "2018"

[dependencies]
http = "0"
k8s-openapi = { version = "0.12", default-features = false, features = ["v1_17"] }
kube = "=0.58.1"

main.rs

use http::Uri;
use kube::{Client, Config};
use std::convert::TryFrom;
use std::str::FromStr;

fn main() {
    let config = Config::new(Uri::from_str("https://not.a.real.cluster").unwrap());
    let _client = Client::try_from(config).unwrap();
}

This panics with:

/Users/x/.cargo/bin/cargo run --color=always --package kube-tokio --bin kube-tokio
    Finished dev [unoptimized + debuginfo] target(s) in 0.08s
     Running `target/debug/kube-tokio`
thread 'main' panicked at 'there is no reactor running, must be called from the context of a Tokio 1.x runtime', /Users/x/.cargo/registry/src/github.com-1ecc6299db9ec823/tower-0.4.8/src/buffer/service.rs:76:9
stack backtrace:
   0: rust_begin_unwind
             at /rustc/53cb7b09b00cbea8754ffb78e7e3cb521cb8af4b/library/std/src/panicking.rs:493:5
   1: core::panicking::panic_fmt
             at /rustc/53cb7b09b00cbea8754ffb78e7e3cb521cb8af4b/library/core/src/panicking.rs:92:14
   2: core::option::expect_failed
             at /rustc/53cb7b09b00cbea8754ffb78e7e3cb521cb8af4b/library/core/src/option.rs:1241:5
   3: core::option::Option<T>::expect
             at /Users/mjb/.rustup/toolchains/stable-x86_64-apple-darwin/lib/rustlib/src/rust/library/core/src/option.rs:349:21
   4: tokio::task::spawn::spawn_inner
             at /Users/mjb/.cargo/registry/src/github.com-1ecc6299db9ec823/tokio-1.8.1/src/task/spawn.rs:139:28
   5: tokio::task::spawn::spawn
             at /Users/mjb/.cargo/registry/src/github.com-1ecc6299db9ec823/tokio-1.8.1/src/task/spawn.rs:130:9
   6: tower::buffer::service::Buffer<T,Request>::new
             at /Users/mjb/.cargo/registry/src/github.com-1ecc6299db9ec823/tower-0.4.8/src/buffer/service.rs:76:9
   7: kube::client::Client::new
             at /Users/mjb/.cargo/registry/src/github.com-1ecc6299db9ec823/kube-0.58.1/src/client/mod.rs:106:20
   8: <kube::client::Client as core::convert::TryFrom<kube::config::Config>>::try_from
             at /Users/mjb/.cargo/registry/src/github.com-1ecc6299db9ec823/kube-0.58.1/src/client/mod.rs:509:12
   9: kube_tokio::main
             at ./src/main.rs:8:19
  10: core::ops::function::FnOnce::call_once
             at /Users/mjb/.rustup/toolchains/stable-x86_64-apple-darwin/lib/rustlib/src/rust/library/core/src/ops/function.rs:227:5
note: Some details are omitted, run with `RUST_BACKTRACE=full` for a verbose backtrace.

Process finished with exit code 101

Rust async ecosystems are still confusing and vexing for me. I'm surprised here that these non-async functions require a "Reactor".

Is it safe to say that tokio must be used as the runtime with kube-rs?

P.S.

This works:

#[tokio::main]
async fn main() {
    let config = Config::new(Uri::from_str("https://not.a.real.cluster").unwrap());
    let _client = Client::try_from(config).unwrap();
}

I think I just need to go back through my stuff and use tokio instead of async-std, and assume I need the runtime even for these non-async functions.

[clux]

Ah, yeah. Just because a function is not marked as async does not mean they don't necessarily do async stuf under the hood.
In particular, Client::try_from(config), sets up all the layers that's basically using things from hyper, tower, tower-http, and binds async handlers internally (which is probably where it's failing here).

It's probably not a good idea to try this crate without an executor. I think without all the default-features, and possibly only using the config feature, you could maybe do something, but almost certainly nothing to do with the client.

kube builds on almost all the core crates within tokio, and while there are some compatibility layers within async-std that they have under their org, I would not recommend going down that route unless you have to. They are really quite far behind tokio right now.