cmd, pkg/podman: Introduce Image Interface and Unit Tests by DaliborKr · Pull Request #1724 · containers/toolbox

DaliborKr · 2025-10-07T15:44:03Z

Introduces an Image interface based on the conversation in PR #1707.

Similar to how container information is handled (introduced in commits e611969 and ec7eb59), this PR abstracts the representation of an image. This is necessary because podman inspect --type image and podman images return different JSON structures. The Image interface provides a unified way to access image data, with two distinct implementations to handle the different JSON formats.

Updates related functions:

GetImages() now returns an Images iterator, which handles image flattening and sorting internally.
InspectImage() now returns an Image interface instead of a generic map[string]interface{}.
The IsToolboxImage() function has been replaced with an IsToolbx() method on the Image interface.

Adds unit tests: This PR includes unit tests for the new Image interface implementation, covering the output of both podman inspect --type image and podman images.

In reaction to the conversation in PR containers#1707, I made suggested changes to the implementation in terms of how Image information, received from Podman, is represented and treated in the Toolbx code. I used the same procedure as in the case of representing Containers: - Commit e611969 - Commit ec7eb59 In short, the JSON from 'podman inspect --type image' and 'podman images' are different, so logically, there should be different implementations of the JSON.Unmarshaler interface [1] for them as well. The new Image interface provides access to the values parsed from the JSONs and two different concrete types, which are implemented separately to handle the differences in the JSONs. GetImages() now returns an Images iterator-like structure that handles image flattening and sorting internally. InspectImage() returns an Image interface instead of map[string]interface{}, and the IsToolboxImage() function was replaced with the IsToolbx() method on the Image interface. [1] https://pkg.go.dev/encoding/json#Unmarshaler Signed-off-by: Dalibor Kricka <dalidalk@seznam.cz>

Provides Go Unit tests for the Image interface implementation introduced in commit fd715a9. Tested were results of Podman starting on version 1.1.2, which should be sufficient since the minimum required Podman version is 1.6.4 (see commit 8e80dd5). Covered are structures representing podman commands 'podman inspect --type image' and 'podman images'. Signed-off-by: Dalibor Kricka <dalidalk@seznam.cz>

softwarefactory-project-zuul · 2025-10-07T17:02:32Z

Build succeeded.
https://softwarefactory-project.io/zuul/t/local/buildset/5c0d0f34d9124050a0549fb6437fc0c8

debarshiray

Thanks for working on this, @DaliborKr ! My apologies for the delay.

I am still reading through the changes, but one thing popped out at me.

debarshiray · 2026-02-27T22:41:42Z

src/pkg/podman/image.go

+}
+
+// ALREADY EXISTS IN CONTAINER.GO
+//


I guess we need to take a decision about the code here in comments? :)

I think we can move the code common to containers.go and images.go to podman.go.

I took the liberty to do this in #1772

debarshiray · 2026-03-09T23:35:31Z

src/pkg/podman/podman.go

 //
 // If a problem happens during execution, first argument is nil and second argument holds the error message.
-func GetImages(args ...string) ([]Image, error) {
+func GetImages(fillNameWithID bool, sortByName bool, args ...string) (*Images, error) {


Isn't sortByName always set to true or did you have some future use in mind? Or did I miss something? :)

debarshiray · 2026-03-09T23:44:34Z

src/pkg/podman/image.go

+
+func (images *Images) Get() Image {
+	if images.i < 1 {
+		panic("called Containers.Get() without calling Containers.Next()")


Typo alert: should be Images, not Containers. :)

debarshiray · 2026-03-10T00:25:30Z

src/pkg/podman/image.go

+}
+
+func (images Images) Len() int {
+	return len(images.data)


It might be better to change these pre-existing methods from ImageSlice that earlier had value receivers to pointer receivers.

I am not an expert on value versus pointer receivers, and I get confused all the time. It seems that the general advice is to not mix pointer and value receivers for a given type.

In the case of the Images type, the Reset() method must have a pointer receiver because it modifies a field of the type.

In case you wonder how the Swap() method was working, just like I did, it's because in Go slices are references to an underlying array and changing an element of a slice modifies the array and other slices see the same change. The value receiver copies the slice and the underlying array stays the same.

debarshiray · 2026-03-10T00:53:16Z

src/cmd/list.go

 	}

-	sort.Sort(podman.ImageSlice(toolboxImages))
 	return toolboxImages, nil


It looks like you are trying to get rid of this wrapper getImages() function, which is a good point. It also applies to the getContainers() function.

Other than the changes you have already made, I wonder if we need the wrappers to filter Toolbx containers and images. Do we ever use non-Toolbx containers and images?

As far as I can see, the wrappers originated when we were using podman images --filter and podman ps --filter to get the images instead of only podman images and podman ps.

I wonder if we can get rid of the wrappers completely, and if we can do it separately from this commit to keep the changes small.

I made an attempt to split the part where you moved the flattening of the images from getImages() to podman.GetImages() in #1772 I hope I got it right. Please take a look and let me know if I made some mistake. :)

If it works out, then we can do the same for the rest of the code that you moved from getImages() to podman.GetImages(). It help to reduce the size of this pull request, and give you more commits to brag about. :)

This is a step towards eliminating or reducing the code in getImages() by doing everything or more in podman.GetImages(). If nothing else, this removes the need to export Image.FlattenNames() from the podman package. The getImages() function originated as listContainers(), when it invoked 'podman images --filter label=...' through podman.GetImages() separately for each label used to identify Toolbx images, and then joined and sorted the results. This changed in commit 2369da5 when getImages() started invoking 'podman images' only once through podman.GetImages() to get all available images, and then filtered them itself based on the labels. Before this change in commit 2369da5, it probably made some sense to keep podman.GetImages() only as a thin wrapper to invoke 'podman images' with different options, and to do everything else in getImages(). However, since then more is being done inside the podman package (eg., unmarshalling the 'podman images' JSON in commit 5f324d5 and flattening the images in commit 6aab0a6), and getImages() is the only caller of podman.GetImages(). Therefore, it looks awkward to have the code to get all Toolbx images split across two functions in different packages. containers#1724

This is a step towards eliminating or reducing the code in getImages() by doing everything or more in podman.GetImages(). If nothing else, this removes the need to export Image.FlattenNames() from the podman package. The getImages() function originated as listContainers(), when it invoked 'podman images --filter label=...' through podman.GetImages() separately for each label used to identify Toolbx images, and then joined and sorted the results. This changed in commit 2369da5 when getImages() started invoking 'podman images' only once through podman.GetImages() to get all available images, and then filtered them itself based on the labels. Before this change in commit 2369da5, it probably made some sense to keep podman.GetImages() only as a thin wrapper to invoke 'podman images' with different options, and to do everything else in getImages(). However, since then more is being done inside the podman package (eg., unmarshalling the 'podman images' JSON in commit 5f324d5 and flattening the images in commit 6aab0a6), and getImages() is the only caller of podman.GetImages(). Therefore, it looks awkward to have the code to get all Toolbx images split across two functions in different packages. containers#1724 containers#1772

Subsequent commits will use isToolbx() for image labels. So, it can't be in a file that's specific to containers. containers#1724 containers#1772

This is a step towards eliminating or reducing the code in getImages() by doing everything or more in podman.GetImages(). If nothing else, this removes the need to keep a copy of the labels used to identify Toolbx images for getImages(). The getImages() function originated as listContainers(), when it invoked 'podman images --filter label=...' through podman.GetImages() separately for each label used to identify Toolbx images, and then joined and sorted the results. This changed in commit 2369da5 when getImages() started invoking 'podman images' only once through podman.GetImages() to get all available images, and then filtered them itself based on the labels. Before this change in commit 2369da5, it probably made some sense to keep podman.GetImages() only as a thin wrapper to invoke 'podman images' with different options, and to do everything else in getImages(). However, since then more is being done inside the podman package (eg., unmarshalling the 'podman images' JSON in commit 5f324d5 and flattening the images in commit 6aab0a6), and getImages() is the only caller of podman.GetImages(). Therefore, it looks awkward to have the code to get all Toolbx images split across two functions in different packages. containers#1724 containers#1772

This is a step towards eliminating the code in getImages() by doing everything in podman.GetImages(). This removes the need to export the podman.ImageSlice type from the podman package. The getImages() function originated as listContainers(), when it invoked 'podman images --filter label=...' through podman.GetImages() separately for each label used to identify Toolbx images, and then joined and sorted the results. This changed in commit 2369da5 when getImages() started invoking 'podman images' only once through podman.GetImages() to get all available images, and then filtered them itself based on the labels. Before this change in commit 2369da5, it probably made some sense to keep podman.GetImages() only as a thin wrapper to invoke 'podman images' with different options, and to do everything else in getImages(). However, since then more is being done inside the podman package (eg., unmarshalling the 'podman images' JSON in commit 5f324d5 and flattening the images in commit 6aab0a6), and getImages() is the only caller of podman.GetImages(). Therefore, it looks awkward to have the code to get all Toolbx images split across two functions in different packages. containers#1724 containers#1772

DaliborKr added 2 commits October 7, 2025 13:27

DaliborKr requested a review from debarshiray as a code owner October 7, 2025 15:44

debarshiray requested changes Feb 27, 2026

View reviewed changes

debarshiray requested changes Mar 10, 2026

View reviewed changes

debarshiray mentioned this pull request Mar 17, 2026

cmd/list, pkg/podman: Eliminate getImages() by doing everything in podman.GetImages() #1772

Open

debarshiray pushed a commit to debarshiray/toolbox that referenced this pull request Mar 17, 2026

pkg/podman: Shuffle some code around

163d863

Subsequent commits will use isToolbx() for image labels. So, it can't be in a file that's specific to containers. containers#1724 containers#1772

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

cmd, pkg/podman: Introduce Image Interface and Unit Tests#1724

cmd, pkg/podman: Introduce Image Interface and Unit Tests#1724
DaliborKr wants to merge 2 commits intocontainers:mainfrom
DaliborKr:image_interface

DaliborKr commented Oct 7, 2025

Uh oh!

softwarefactory-project-zuul bot commented Oct 7, 2025

Uh oh!

debarshiray left a comment

Uh oh!

debarshiray Feb 27, 2026

Uh oh!

debarshiray Mar 10, 2026

Uh oh!

debarshiray Mar 17, 2026

Uh oh!

debarshiray Mar 9, 2026

Uh oh!

debarshiray Mar 9, 2026

Uh oh!

debarshiray Mar 10, 2026

Uh oh!

debarshiray Mar 10, 2026

Uh oh!

debarshiray Mar 17, 2026

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

2 participants

Conversation

DaliborKr commented Oct 7, 2025

Uh oh!

softwarefactory-project-zuul bot commented Oct 7, 2025

Uh oh!

debarshiray left a comment

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

2 participants