lovelysystems/lovely-pytest-docker

Faulty service endpoint output on Windows 10 + Docker Desktop

Opened this issue · 4 comments

Same Issue as for pytest-docker
See avast/pytest-docker#78

frisi commented

thanks for the heads up @KUZJurk and sorry for the late reply.

atm we do not need or claim windows support for this package.
also the linked issue/pullrequest is still not merged and has an open discussion (lack of ip6 support, does not support hostnames)

however, if you provide a pull request that solves your problem and does not affect our linux/mac setups, we'll be happy to review and merge.

Hi,

Yeah, no big deal.
Currently i have a kind of monkeypatch in my code, where I override the port_for function:

# fix/monkeypatch for pytest-docker endpoint output '<port>\r\n\x1b[0m'
class MyDockerServices(Services):
    def port_for(self, service, port):
        """Get the effective bind port for a service."""

        # Lookup in the cache.
        cache = self._services.get(service, {}).get(port, None)
        if cache is not None:
            return cache

        output = self._docker_compose.execute(
            'port', service, str(port)
        )
        endpoint = output.strip()
        if not endpoint:
            raise ValueError(
                'Could not detect port for "%s:%d".' % (service, port)
            )

        # Usually, the IP address here is 0.0.0.0, so we don't use it.
        match = endpoint.split(':', 1)[1]
        # fix/monkeypatch for pytest-docker endpoint output '<port>\r\n\x1b[0m'
        match2 = int(match.split('\r', 1)[0])

        # Store it in cache in case we request it multiple times.
        self._services.setdefault(service, {})[port] = match2

        return match2

Hope it helps.

frisi commented

thanks for showing windows users a way to work around the issue.
iiuc however, this breaks the usage for non-windows users and can't be considered a real solution.

No problem.

If the framework works flawlessly on linux/mac, then the endpoint string should be just the ip:port, right?
After you split of the port you would have just the port as string.
So the split of just the port on '\r' should return just the port, making the solution kind of a real solution or not?
If not, there should be occasions where the port on linux/mac can have '\r' in it.

Would be glad for corrections on my assumptions.