google / google/go-containerregistry
Support v1 tarball as stream?
- Dominant language
- Go
- Stars
- 4k
- Forks
- 686
- Avg merge
- 2d 12h
- Merged PRs (30d)
- 26
Description
Is it possible to extend package v1/tarball to support streaming access, i.e. create a `v1.Image` and `v1.ImageIndex` not from a file on disk, but from a tar stream instead?
As far as I can see, the only options are [ImageFromPath](https://pkg.go.dev/github.com/google/go-containerregistry@v0.4.0/pkg/v1/tarball#ImageFromPath) and (the function it wraps) [Image](https://pkg.go.dev/github.com/google/go-containerregistry@v0.4.0/pkg/v1/tarball#Image). The former takes an actual path, while the latter works with an [Opener](https://pkg.go.dev/github.com/google/go-containerregistry@v0.4.0/pkg/v1/tarball#Opener). I thought the latter might work, but it calls the `Opener` multiple times and reads things through, which wouldn't work with a stream.
My use case is that I am getting an image stream - e.g. a tar stream in oci tarball layout format, or just running `docker buildx build --output=type=oci` which outputs to stdout - and was to then use it. I might save it to v1/layout or push it to a registry or a whole bunch of things, but first I need to make it useful to other parts of this library, which means I need to generate a `v1.Image` or `v1.ImageIndex`.
Contributor guide
Research direction
Start with the v1/tarball package and its ImageFromPath, Image, and Opener entry points to understand the repeated-read requirement. Define how a tar stream should produce a v1.Image or v1.ImageIndex and verify the result can be consumed by the library's existing image, layout, or registry operations.
Written by the indexing model from the issue text.
Assessment
- Tech stack
- docker, go
- Domain
- api, devtools
- Issue type
- Feature
- Difficulty
- 5/5
- Estimated time
- Over a week
- Activity status
- Stale
- Clarity
- Mostly clear
- Newbie friendliness
- 30/100