Proposal: Move skopeo's experimental-image-proxy into container-libs

[giuseppe]

Skopeo's experimental-image-proxy command (~1000 lines in cmd/skopeo/proxy.go) exposes a JSON+fd-passing protocol over a Unix socket pair, allowing non-Go programs to fetch container images. The primary consumer is https://github.com/containers/containers-image-proxy-rs.

The proxy is almost entirely a thin wrapper around containers/image APIs.

The proposed approach is to extract the proxy handler into a new package under container-libs so that it can be reused by other tools.

Once this proxy library is in place, #651 can be reworked to use it instead of introducing its own JSON-RPC server.

@mtrmac @cgwalters PTAL

[mtrmac]

I think it’s not quite that simple, because the proxy consumes various CLI options that exist only in Skopeo.

So I think the package would probably need to be split into infrastructure (some package in container-libs) + operation handlers (perhaps remaining in Skopeo) + top-level setup (in Skopeo).

But then there’s things like containers/skopeo#1844 (comment) … the argument parsing approach in the proxy is rather too manual, probably unnecessarily (and that is from Go 1.17 times, we might be able to do better with generics) … and … that sort of brings us back to last month’s “should we use a pre-existing RPC?” discussions.

[mtrmac]

Also, from a RPM packaging point of view, we are not currently set up to package executables out of container-libs. That’s a technically trivial thing but the process to change that would be somewhat costly.

[giuseppe]

I think it’s not quite that simple, because the proxy consumes various CLI options that exist only in Skopeo.

So I think the package would probably need to be split into infrastructure (some package in container-libs) + operation handlers (perhaps remaining in Skopeo) + top-level setup (in Skopeo).

But then there’s things like containers/skopeo#1844 (comment) … the argument parsing approach in the proxy is rather too manual, probably unnecessarily (and that is from Go 1.17 times, we might be able to do better with generics) … and … that sort of brings us back to last month’s “should we use a pre-existing RPC?” discussions.

yes, it won't be a simple mv but we need to split the library functionalities from the skopeo plumbing. The functionality can be still be exposed through skopeo using the same experimental proxy.

Also, from a RPM packaging point of view, we are not currently set up to package executables out of container-libs. That’s a technically trivial thing but the process to change that would be somewhat costly.

I don't think we need to do this. Just moving the library functionalities from skopeo to container-libs

[cgwalters]

But then there’s things like containers/skopeo#1844 (comment) … the argument parsing approach in the proxy is rather too manual, probably unnecessarily (and that is from Go 1.17 times, we might be able to do better with generics) … and … that sort of brings us back to last month’s “should we use a pre-existing RPC?” discussions.

I think jsonrpc-fdpass addresses both of those points. There's already well-understood tooling used for json-rpc, and the -fdpass is IMO a very small scoped extension to it.

In my defense, json-rpc was kind of less widely used at the time of the proxy introduction, I think LSP was the main user, but since then there's MCP and now ACP.

[cgwalters]

Yeah...a side goal of having the core functionality in container-libs is we can expose it from podman too, meaning bootc would switch to requiring podman || skopeo, not both.