Nicola Sella

> This will reduce the overlap between PodmanClient and PodmanCommand to minimal or none It means that I really don't want to have duplicate features. The cli features should be...

One more thing that comes to mind, and then I'll let the PR rest for a bit, is that in podman-py we don't test on win/macos. The reason is that...

> We have actually used the code in this PR successfully, to run our CI tests that require nested virtualization on GitHub Actions. To our surprise, it worked not only...

Hey, firstly, thanks a lot for using `podman`. Interesting report. Surely something worth considering for your use case and for podman's future in general. > So maybe the easiest short-term...

Reason for closing. This feature requires a very deep level of refactor or a lot of time for investigation, which currently are out of my capacity. I would rather reopen...

hey @djasa , thanks for the detailed report. you are correct, `exec_run` differs in the implementation from docker python sdk. There are missing kwargs and some of the functionalities might...

Got it, I will put it in the backlog. Thanks for the report, we got more interest around `exec_run` recently, so I hope to have it fixed soon

Podman-py already supports windows "in a way". Let me be clear. Currently, podman works on Windows in a WSL2 environment, and that's Linux. As long as podman-py is installed inside...

> Got it, makes sense. It is a way indeed to use podman-py bindings in Windows. I guess my perspective here is from a Python application running on the Windows...

I was trying the same right now. Ideas: 1. It might be worth playing with `socket(socket.AF_INET, socket.SOCK_STREAM)`. 2. It is definitely possible to [interoperate with AF_UNIX and WSL~~2~~](https://devblogs.microsoft.com/commandline/windowswsl-interop-with-af_unix/) (Edit: not...