-
-
Notifications
You must be signed in to change notification settings - Fork 97
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Add podman support #300
Comments
I've just tried playing around with podman too and hit the same thing, but I'm not convinced it is FluentDocker's fault. This failure occurs when parsing the result of "Health": {
"Status": "",
"FailingStreak": 0,
"Log": null
} FluentDocker is trying to parse Not had much luck finding out why this is the case in podman yet, and don't have docker available to compare with just yet. |
Running on Fedora and Your issue might be mac specific. I'd still say this library needs to investigate given that the JetBrains container tooling is working flawlessely. |
Nonetheless, I've dumped my There's two issues with it. |
Definitely more issues once you get past that, failing on the following command:
Several of these properties (eg Source, IPv6, CreatedAt) are not available on either machine I've tested with, and the --format fails very ungracefully when that happens. Within FluentDocker, ID and Name are the only ones currently used, so defensively we could avoid trying to request and parse what we don't need here (though as of now I don't know if this class is public / something you could or would depend on in client code). Next, it crashes when FluentDocker tries to parse the output of
And docker's output looks like this:
and it cannot parse Once again, it looks like this is parsed by FluentDocker but without any internal usage, so could be removed for a more defensive approach to parsing output. It feels a bit rude to go chopping all of this away to support podman here, and ideally podman output would be truly interchangeable with docker output and we'd have none of these issues, but maybe a case could be made for a more generally defensive approach to FluentDocker which would just so happen to solve the immediate problems - remove unused code, and only parse what is strictly needed today? After making all of these amendments in a local branch, FluentDocker appears to work for me, with podman v4.6.2, within the scope of my limited use in test projects (3 different containers). I'm sure there's a lot more edge cases beyond this. |
Have published #303 as a hopefully amicable first-pass support for podman, obviously subject to the maintainer actually wanting to bring this in. |
Nice work @Rory-Reid - I greatly appreciate it! I had one comment, could you please check it out? Cheers |
Any chance this can progress? |
@atrauzzi sorry, yes, I'll have a look this weekend and make sure to get this going! |
Given Dockers decline in reputation over the last while, there's a lot of movement towards podman.
I just tried using this library to run a container on my local podman (linux, Fedora, no Windows!) environment and got the following:
Anyway, I run containers all the time for local development using jetbrains tooling and CLI. I have the
docker
anddocker-compose
commands available, mapped to their fully API compatible podman equivalents (if it matters).The text was updated successfully, but these errors were encountered: