Replies: 2 comments
-
I'm not opposed, but there would be a significant amount of work to abstract Build into an interface that could be pluggable. I don't know when or if the core team will have time to work on this. For some context on that issue, in the early days, Podman called out to Buildah, instead of vendoring Buildah code as we do now. The original approach had the issue of requiring both Buildah and Podman to be installed at the same time, which is a dealbreaker for some distributions if we want to be in the default install (Go binaries are absolutely gigantic, I think Podman is in the ~45MB range, Buildah slightly smaller - that's a lot of disk space in an installer image). Podman and Buildah use the same code to build, but occasionally they fall out of step if a newer version of Buildah is released and a fresh Podman has not been released to take advantage of it. |
Beta Was this translation helpful? Give feedback.
-
We are also adding a lot of the popular items in buildkit into Buildah which eventually vendors into Podman. Are you looking for a specific feature? |
Beta Was this translation helpful? Give feedback.
-
Hi Podman Team.
The issue #12062 brings me here to ask.
I would like to ask if it's planned to having some 'podman build' plugins? Or interchangeable build engines in Podman? Some way how I can use buildah/builkit/whatever under the hood of 'podman build'. Or this is not in Podman philosophy?
Maybe this is just my subejctive feeling, but from developer experience perspective it's more natural using 'podman build' . That's how we - developers - are thinking about building images. Old habits.
Beta Was this translation helpful? Give feedback.
All reactions