fussybeaver / bollard

Docker daemon API in Rust
Apache License 2.0
882 stars 133 forks source link

Is it possible to use list_containers without type params? #412

Closed flrgh closed 3 months ago

flrgh commented 3 months ago

:wave: Hiya!

I was trying to get up and running with the library when I discovered that this will not compile:

use bollard::Docker;

#[tokio::main]
async fn main() {
    let docker = Docker::connect_with_defaults().unwrap();

    let containers = docker.list_containers(None).await.unwrap();
    dbg!(containers);
}

The end result of the bounds on the T in Option<ListContainersOptions<T>> are that even passing None requires a type parameter:

error[E0283]: type annotations needed
    --> src/docker.rs:7:29
     |
7    |     let containers = docker.list_containers(None).await.unwrap();
     |                             ^^^^^^^^^^^^^^^ ---- type must be known at this point
     |                             |
     |                             cannot infer type of the type parameter `T` declared on the method `list_containers`
     |
     = note: cannot satisfy `_: Into<String>`
note: required by a bound in `container::<impl Docker>::list_containers`
    --> /home/user/.local/cargo/registry/src/index.crates.io-6f17d22bba15001f/bollard-0.16.1/src/container.rs:1197:12
     |
1192 |     pub async fn list_containers<'de, T>(
     |                  --------------- required by a bound in this associated function
...
1197 |         T: Into<String> + Eq + Hash + Serialize,
     |            ^^^^^^^^^^^^ required by this bound in `container::<impl Docker>::list_containers`
help: consider specifying the generic argument
     |
7    |     let containers = docker.list_containers::<T>(None).await.unwrap();
     |

Adding an explicit type param fixes this:

-    let containers = docker.list_containers(None).await.unwrap();
+    let containers = docker.list_containers::<String>(None).await.unwrap();

It's definitely not the end of the world, but I did find it a little awkward. I'm sort of a rust newbie, so I thought I'd ask: is there a better way for me to write this code?

fussybeaver commented 3 months ago

Yeah, it's definitely a gnarly point of the library that's caused by the underlying parameter to list_containers, which takes a struct with a generic parameter T that we use to ingest strings. I think it'd be nice to get rid of this at some point, but it'd need some non-trivial refactoring...

flrgh commented 3 months ago

I think it'd be nice to get rid of this at some point, but it'd need some non-trivial refactoring...

Ah, gotcha--it's all good. I was thinking that I was just missing something. Thanks for chiming in!