Rethink usage pattern about testcontainers-rs HOT 7 CLOSED

A problem with solution 1 is that in order for it to make sense, it have to be implemented on the Image trait like this:

pub trait Image
where
    Self: Sized + Default,
    Self::Args: IntoIterator<Item = String>,
{
    type Args;

    fn start(self) -> Container<DockerCli, Self> {
        let docker = DockerCli::new();

        docker.run(self)
    }

    ...
}

1. This forces the usage of a specific Docker client (not nice but would be ok)
2. In order to use methods from a trait, the trait needs to be in scope. Here we are back again with a necessary import from testcontainers.

from testcontainers-rs.

I might be thick but I don't really get the issue. Can't the image crate just compile with whatever testcontainers version you're using assuming the minor versions are the same?

from testcontainers-rs.

It needs to be the exact same version actually: Cargo needs to be able to find a match between the semver range of the testcontainers dependency for the image crate as well as the one that the user code depends on which tries to start the image.

If the two don't match, the code will not compile because the stuff you import directly from testcontainers is different from what the image crate gets compiled against.

from testcontainers-rs.

So if we change the dependency on things to something like:

[dependencies]
testcontainers = { path = "../../testcontainers", version = "0.2" }

for the images. And a user uses testcontainers version "0.2.2" then it won't just work? Why would it not compile the image against 0.2.2 then as well?

from testcontainers-rs.

This one would work. As I said, cargo needs to be able to find a 'match' between the two semver ranges that are specified. 0.2.2 is within the semver range 0.2.x so it should work.

from testcontainers-rs.

You cannot use path in combination with version

from testcontainers-rs.

You can, cargo will use the version upon publishing and the path for local development.

from testcontainers-rs.