ContainerRegistry: Separate registry operations into ImageSource and ImageDestination protocols
#148
Conversation
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
euanh
added
kind/enhancement
euanh
force-pushed
the
source-destination-protocols
branch
5 times, most recently
from
4143511 to
ce27304
Compare
euanh
changed the title
ImageSource and ImageDestination protocols
euanh
force-pushed
the
source-destination-protocols
branch
2 times, most recently
from
45d10c6 to
800f328
Compare
euanh
force-pushed
the
source-destination-protocols
branch
2 times, most recently
from
92e6189 to
560f45a
Compare
euanh
force-pushed
the
source-destination-protocols
branch
3 times, most recently
from
2eeacd9 to
99e852e
Compare
euanh
force-pushed
the
source-destination-protocols
branch
from
99e852e to
1c129a7
Compare
euanh
added a commit
that referenced
this pull request
Jul 11, 2025
Motivation ---------- When the `--from scratch` option is used, `containertool` does not download the [scratch](https://hub.docker.com/_/scratch) from Docker Hub - instead it synthesizes a suitable empty image. Currently this is handled by making the source client optional, but that causes `nil` checks to spread everywhere. Now that we have the `ImageSource` protocol (#148) we can instead use a [null object](https://en.wikipedia.org/wiki/Null_object_pattern) which can only return an empty image. This allows the `nil` checks to be removed and lets the same code path handle images built on real base images and the scratch base image. Modifications ------------- * Add `ScratchImage`, a null object implementing the `ImageSource` protocol * Remove special cases previously needed to make the image source optional. * Remove the option to pass `JSONEncoder` and `JSONDecoder` instances to `RegistryClient`. Specific configuration options must be used to match the requirements of the image specification, so there is not much value in allowing the user to pass in an encoder with an unknown configuration. Result ------ * Fewer special cases * No functional change Test Plan --------- Existing tests continue to pass.
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Motivation
Currently,
RegistryClienthandles uploading and downloading container images to and from a registry. In fact,containertoolcreates two clients: one is used only to download images from the source repository, and the other is used only to upload images to the destination. Registries are read/write, but in the future we may need to handle sources of images which are read-only or write-only - for example when writing a container image out to an archive on disk.This change adds two new protocols, splitting up the operations needed to upload and download images. This allows for future clients which cannot handle both sets of operations.
Modifications
ImageSourceandImageDestinationprotocols, defining the functions needed to download and upload images, respectively.RegistryClientextensions which implement theImageSourceandImageDestinationprotocols.Result
Refactoring. No functional change, but responsibilities of different objects are clearer.
Test Plan
Existing tests continue to pass.