Implement a way to create an image from scratch.

[dlorenc]

Thoughts on the name: parts.Image?

The idea would be a constructor that takes an ordered list of layers and a config file, and assembles them into an Image. This would be useful for modifying the config of an existing image, modifying layers, or other mutation operations.

[mattmoor]

I think we want two constructs:

• scratch.Image: the empty image, maybe even a singleton like authn.Anonymous (tho in hindsight, we don't get Anonymous in the godoc, so this is likely choice we should walk back before it's too late).
• append.Image: take a base, and what to augment it with.

WDYT?

[dlorenc]

We need more than just append, although I guess a "SetLayers" call could be constructed out of a series of appends...

If we also had something to set the Config, I think that would be enough.

Then modifying the Config from an existing Image would look like:

Create a scratch.Image, set the Config on that.
Append in each layer from the existing Image

[imjasonh]

authn.Anonymous is in the godoc: https://godoc.org/github.com/google/go-containerregistry/authn -- it's just very well hidden. I'd rather file a godoc bug than modify the API to suit godoc's current behavior.

[mattmoor]

I retract my previous statement (I see it now), singletons are fine. :)

[mattmoor]

@dlorenc Why not just take a slice of layers to append? :)

[dlorenc]

Yeah that works, we just need a way to also set Config independently. I'm not a big fan of the way it happens in Python, with overrides being tacked onto the append.

[imjasonh]

What was the rationale for making v1.Image an interface instead of a struct with exported fields? That would let you modify the value returned by remote.Image(...) directly, without needing some kind of append.Image(remoteImage, newLayers...) method.

[mattmoor]

That necessitates eager fetching, there is signficant performance advantage to laziness.

e.g. This code should be able to copy an image between two repositories on the same registry (via mounting) without ever hitting the blob endpoint.

[imjasonh]

What if fields from blobs were only populated after calling some method? How large are config blobs expected to get?