Expose docker.from_env() parameters

testcontainers.core.DockerClient calls docker.from_env() it it’s constructor. This method has a few parameters that will be useful to be exposed (see reference)

Ideally testcontainers.core.DockerClient and conversely testcontainers.core.DockerContainer should expose these parameters.

[tillahoffmann]

So basically, we can add **kwargs to the DockerClient constructor and pass that to the .from_env method. Similarly, in the DockerContainer class, we can pass the kwargs to the DockerClient.

That sounds reasonable. But let’s pass a dictionary docker_client_kw to DockerContainer and then unpack the dictionary in the call to DockerClient akin to gridspec_kw matplotlib.pyplot.subplots.

[thedrow]

I think it could be useful to implement it this way but it doesn’t really abstract the Docker client which isn’t bad per-se if the project’s scope is limited only to Docker and not other kind of containers (BSD Jails could be useful for example). However, we do need to consider that we might switch from the official docker client at some point since it may be phased out or since Docker Inc will unexpectedly go bankrupt etc.

I admit these risks are rather minor, but violating encapsulation needs better reasons than useful.

The design we’re looking for is the ability to pass a ContainerClientConfiguration object which we can use for testing by mocking the object, provide configuration to multiple container implementations and maybe something I haven’t thought of.