incompatible with python docker sdk

[cosama]

I am trying to run a python program using tqdm through the docker python sdk: https://docker-py.readthedocs.io/en/stable/index.html.

The are doing some weird stuff with the stdout and stderr, it looks to me like those are being passed through some form of socket and then captured and returned as a stream of bytes.

This seems to not go well with tqdm, I am not an expert on this, but it looks like output only really gets returned when an newline is detected (but I might be wrong here).

I am not sure if this is even the right place or if it would be a more suitable to file an issue with the docker sdk people, but I thought I have to start somewhere.

Here code to reproduce what I am talking about:

import docker
client = docker.from_env()
container = client.containers.run(
    "tqdm/tqdm",
    [
        "-u",
        "-c",
        """
import tqdm
import time
for r in tqdm.tqdm(range(100)):
    time.sleep(0.1)
"""
    ],
    entrypoint="python",
    detach=True,
)
for line in container.logs(stream=True):
    print(line.decode("utf-8").strip())

It only returns the status bar at the very end. I hope I used the entry point properly with the tqdm docker image, but I also tested this with some other images and it produced the same result.

I run this with Python 3.8.10 and the docker sdk version 5.0.3 installed with pip install docker.

I was hoping there would be some work around, maybe replace \r with something like \r\n and then parse it in the output, but not sure how I would go about that expect for adding additional print statements myself.

By the way tqdm is a really great tool, thanks for putting so much work into it.

[casperdcl]

duplicate of #771?

[cosama]

@casperdcl I suspect this is actually an issue on the docker-py side. I filled an issue there as well. I don't think it is a duplicate. Back when the docker compose issue was posted, compose was still based on python but they used their own back end and didn't use docker-py as far as I can tell. I suspect it has the same origin though. docker compose is now implemented in go and #771 might not be relevant anymore. Probably worth testing. If that is fine with you I will see what the docker-py people think about this and leave it open for now.