Document Podman support

[huonw]

Describe the bug

In https://github.com/pantsbuild/pants/pull/20470, we added support for Podman. It seems like this is automatically enabled if the pants.backend.experimental.docker.podman backend is loaded, but can be disabled with https://www.pantsbuild.org/2.20/reference/subsystems/docker#experimental_enable_podman. In addition, option is only available when the backend is added, but this isn't obvious from the docs, so I imagine people may try setting experimental_enable_podman = True without the backend and get confusion.

This process doesn't seem to be described in the docs anywhere, e.g. no mention of Podman in https://www.pantsbuild.org/2.20/docs/docker, and I don't think the pants.backend.experimental.docker.podman appears in the docs either, since there's no subsystem or similar associated with it, just that option.

Suggestion: one or more of:

• expand the docs of experimental_enable_podman to describe how to load the backend
• add description to the main docker text docs
• fold this into the pants.backend.experimental.docker completely (the majority of the support has to be hard-coded into it, anyway) without the extra backend. The experimental_enable_podman option would move into this backend and then flip to defaulting to False, so someone could enable Podman by setting that option, rather than loading the new backend. (This is related to documentation because it would simplify what we need to describe to users)

Pants version

2.20

OS

N/A

Additional info N/A

[sureshjoshi]

Whoa! We have official experimental podman support? That's great! I've been symlinking binaries like a chump the past few months.

[sureshjoshi]

I obviously haven't dug into it, and will thus have to to answer my own question, but why wouldn't enabling Docker automagically enable podman?

Is the concern about what we do if the user has BOTH installed?

More specifically, I guess I'm a proponent of option 3 above, in that, I'd rather enable Docker and a toggle - so long as that doesn't require having both installed.

[sureshjoshi]

@xlevus @huonw @kaos @tgolsson - Adding you all since you're in the PR about Podman.

Is there a reason to use a separate backend at all? As in, I don't know how many Docker + Podman users there are, and the official Podman documentation suggests alias docker=podman from the get-go.

To the original PR's point, Docker and Podman aren't perfectly 1:1 - but they're pretty close.

My instinct would be to automatically check for docker, then podman, by default in the Binary search (inside of pants.backend.docker) - and if there was a flag at all, it would be a global flag to explicitly specify one or the other, or maybe flip the search order (but even this seems a little silly to me, because that would imply someone wants to default to podman on machines with both docker and podman installed, but doesn't want to explicitly specify podman - feels very edge-case)

Logic being:

• Companies who want to guarantee EXACTLY what container tool is in use - could specify one or the other via global option
• Casual users who treat Docker/Podman as interchangeable-ish shouldn't care
• My guess is that, there aren't a large number of developers with both installed (I've never met one, anyways)

Thoughts? Opinions?

[kaos]

I've no strong opinions either way here.

What I think Pants is lacking, is to have a higher level configuration that takes care of all the nitty gritty details. Most of my projects are setup the same, and having a one flip switch that would turn all the knobs the right way would be awesome. And with that, the layout of backends and subsystems options is less of an issue.

[xlevus]

Postman and docker aren’t 1:1 matches. They’re close but not exact. With the implementation in an experimental backend we can (in theory) flesh out more differences when it’s explicitly enabled and not have “it’s broken” be the default.

(There’s some caveats here when docker is symlinked to podman, and it works but not quite)

Additionally, I was told some parts of the docker integration will/does use the API and not the CLI, which won’t work for podman.

On Fri, May 31, 2024 at 1:31 AM, SJ @.***(mailto:On Fri, May 31, 2024 at 1:31 AM, SJ < wrote:

@.(https://github.com/xlevus) @.(https://github.com/huonw) @.(https://github.com/kaos) @.(https://github.com/tgolsson) - Adding you all since you're in the PR about Podman.

Is there a reason to use a separate backend at all? As in, I don't know how many Docker + Podman users there are, and the official Podman documentation suggests alias docker=podman from the get-go.

To the original PR's point, Docker and Podman aren't perfectly 1:1 - but they're pretty close.

My instinct would be to automatically check for docker, then podman, by default in the Binary search (inside of pants.backend.docker) - and if there was a flag at all, it would be a global flag to explicitly specify one or the other, or maybe flip the search order (but even this seems a little silly to me, because that would imply someone wants to default to podman on machines with both docker and podman installed, but doesn't want to explicitly specify podman - feels very edge-case)

Logic being:

• Companies who want to guarantee EXACTLY what container tool is in use - could specify one or the other via global option
• Casual users who treat Docker/Podman as interchangeable-ish shouldn't care
• My guess is that, there aren't a large number of developers with both installed (I've never met one, anyways)

Thoughts? Opinions?

— Reply to this email directly, view it on GitHub, or unsubscribe. You are receiving this because you were mentioned.Message ID: @.***>

[sureshjoshi]

Postman and docker aren’t 1:1 matches. They’re close but not exact.

Yeah exactly. In my experience, as just a regular ol' Podman convert from Docker - I hadn't run into a single problem until I started doing multi-platform builds and had to dig in deeper with buildx and some of the more nuanced commands. That's where things start falling apart.

My hope would be that we could cover that 80/20 use case, reasonably (explicitly noting that Docker is supported, Podman is "supported").

With the implementation in an experimental backend we can (in theory) flesh out more differences when it’s explicitly enabled and not have “it’s broken” be the default.

Good point, I guess there's no rush to merge them. An experimental backend does allow a lot more flexibility just by sheer semantics :) Not sure if that would be substantially different than an experimental flag on the Docker backend though 🤷🏽

some parts of the docker integration will/does use the API

Yeah, I'm guessing that's referring to bollard?

I thought Podman maintained a compatibility layer API with Docker, but it's been a few years since I've looked into it - and I don't know if it's drifted.

[kaos]

some parts of the docker integration will/does use the API

Yeah, I'm guessing that's referring to bollard?

Yep. However, that's for the environment support only, so technically wouldn't be a blocker for the docker backend. However, there's been some ideas floated about dropping the CLI integration and go full API also for the docker backend, but there's nothing committed along those lines currently.