[Discussion] Reason to maintain two different implementation?

[endertunc]

This library currently supports two way to communicate with docker;

• CLI using docker command
• HTTP using bollard (unofficial) Rust SDK for Docker

I do think that this approach bring some unnecessary complexity without a real benefit (I would like to be corrected on this one if I missed something). Every feature has to be implemented twice with different approach, for example, sync vs async.

To my understanding, testcontainers-rs is the only one which depends on docker command directly. I have been looking some of the popular implementation like java, golang and node, they all seem to take the second approach which is using SDK for Docker.

Given the fact that wherever you have docker command available, I believe you also have your docker daemon running on UNIX socket therefore there is no need to directly talk with docker command. (that's what docker command talks to as well if I am not mistaken)

I would assume that CLI implementation is around for historical reasons but I don't see any benefits of keeping it around in the long term.

Of course this is my humble opinion and I would like to hear what others think. :)

cc @thomaseizinger

[thomaseizinger]

I would assume that CLI implementation is around for historical reasons but I don't see any benefits of keeping it around in the long term.

Correct, it was the first implementation and allowed us to progress quickly.

I am open to having it removed. One problem is that we will force an async runtime onto every user which isn't great. There will be plenty of users that don't write async Rust code.