search

testcontainers / testcontainers-rs

A library for integration-testing against docker containers from within Rust.
https://rust.testcontainers.org
Apache License 2.0
769 stars 141 forks source link

[Discussion] Reason to maintain two different implementation? #508

Closed endertunc closed 7 months ago

endertunc commented 1 year ago

This library currently supports two way to communicate with 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 commented 1 year ago

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.