How to install async_tungstenite correctly?

I had this issue a couple times now. I find a crate, install it. Then run an example and something is missing. Like there is no documentation on it.

use async_tungstenite::async_std::connect_async;

cargo.toml

async-tungstenite = "*"
error[E0432]: unresolved import `async_tungstenite::async_std`
  --> src\main.rs:18:24
   |
18 | use async_tungstenite::async_std::connect_async;
   |                        ^^^^^^^^^ could not find `async_std` in `async_tungstenite`

You probably need to enable the async-std-runtime feature on async_tungstenite

If you check the Cargo.toml of async_std you'll see it requires different features for different examples

1 Like

For more information on the available optional features of this crate, see the docs:

This crate is based on tungstenite Rust WebSocket library and provides async bindings and wrappers for it, so you can use it with non-blocking/asynchronous TcpStreams from and couple it together with other crates from the async stack. In addition, optional integration with various other crates can be enabled via feature flags

  • async-tls: Enables the async_tls module, which provides integration with the async-tls TLS stack and can be used independent of any async runtime.
  • async-std-runtime: Enables the async_std module, which provides integration with the async-std runtime.
  • async-native-tls: Enables the additional functions in the async_std module to implement TLS via async-native-tls.
  • tokio-runtime: Enables the tokio module, which provides integration with the tokio runtime.
  • tokio-native-tls: Enables the additional functions in the tokio module to implement TLS via tokio-native-tls.
  • tokio-rustls-native-certs: Enables the additional functions in the tokio module to implement TLS via tokio-rustls and uses native system certificates found with rustls-native-certs.
  • tokio-rustls-webpki-roots: Enables the additional functions in the tokio module to implement TLS via tokio-rustls and uses the certificates webpki-roots provides.
  • tokio-openssl: Enables the additional functions in the tokio module to implement TLS via tokio-openssl.
  • gio-runtime: Enables the gio module, which provides integration with the gio runtime.

The docs.rs website also provides an auto-generated list of all feature flags, but that’s generally less helpful than explanations in the documentation. (For crates that didn’t properly document their optional features this is very useful though.) You see it with the “feature flags” button at the top. Each headline is a feature flag, the “default” flag is always activated by default (but one can opt out of that). Under each feature flag, a list of things appears that are either

  • another feature flag of the current crate that will be implied
  • an optional dependency of the current crate that will be activated
  • a feature of a dependency of the current crate that will be activated

Also, every optional dependency automatically becomes a feature flag with the same name, so the first two cases in the above listing are kind-of actually technically the same.

There’s also an unstable rustdoc feature that you sometimes come across which makes features way nicer to understand: You come across this even though it’s unstable, because docs.rs uses nightly Rust for generating documentation. An example crate that uses it that comes to mind is tokio. In the tokio docs, you will see little indicators on every documented item or module that is only optionally available, indicating what feature it belongs to. Or on a page for such an item or module you see a more lengthy indicator at the top of the page saying something like “Available on crate feature foo only.” We can hope that this kind of thing becomes stable eventually, and maybe even activated by default and happening automatically, so the crate ecosystem can become more widely better documented in this way, without explicit effort by the crate authors.