Singularity equivalent to "docker image list"

Question

Is there a singularity equivalent to docker image list? The Singularity 3.8 documentation states that

All cache entries are named using a content hash

which makes sense when checking for identical layers/images, but has no semantic meaning whatsoever. Compare this to docker's docker image list which lists the images that you already have with semantically meaningful names (e.g. ubuntu, ros). Example:

$ singularity cache list -v
NAME                     DATE CREATED           SIZE             TYPE
496a66ed93a0244167905e   2021-07-23 18:20:26    0.57 KiB         blob
6b05187eae388023ea3f9d   2021-07-23 18:20:26    0.34 KiB         blob
a31c7b29f4ad2bd9467389   2021-07-23 18:20:26    27.24 MiB        blob
sha256.9b0dafaadb1cd1d   2021-07-24 14:37:56    90.46 MiB        library
sha256.cb37e547a142499   2021-07-23 18:10:22    55.39 MiB        library
b3e2e47d016c08b3396b5e   2021-07-23 18:20:29    26.45 MiB        oci-tmp

versus

$ docker image list
REPOSITORY               TAG        IMAGE ID       CREATED         SIZE
foxy-moveit2-tutorials   latest     ca302410c537   3 weeks ago     5.09GB
foxy-moveit2             latest     ba2e29d36a81   3 weeks ago     4.85GB
ros                      galactic   717c275e4609   5 weeks ago     675MB
ros                      foxy       5459f09fa2f1   5 weeks ago     723MB
devrt/xserver            latest     31e1d3e1887d   13 months ago   293MB

An alternative would be to define a specific directory where all the pulled images are placed, and lits its contents:

$ singularity pull --dir ~/singularity_images/ docker://ros:foxy
$ ls singularity_images/
ros_foxy.sif

In short, singularity leaves you wondering about the images that you have already downloaded, because the content hashes lack semantic meaning.

score 7 · Accepted Answer · answered Jul 27 '21 at 10:39

The Singularity equivalent of docker image ls is ls *.sif.

This is one of the key differences between Docker and Singularity: a service with a centralized collection of local images available to all group members vs. images as files that can be run by anyone on any computer with singularity installed. The cache listing you show is also specific to your user (generally ~/.singularity/cache), though build actions do end up with a shared cache at /root/.singularity/cache as they require sudo privileges.

Another important distinction between docker image ls and singularity cache list is after clearing your singularity cache, the sif you generated still works as expected. Removing a docker image is the equivalent of deleting that sif file.

If an image is likely to be used by others, it's worthwhile to set up a shared location on the filesystem. This way you can also separate users who have permission to create images from those who just need to use them.

let's assume that among these blob files, several were part of a single docker image, which i want to remove now. Is there a way to re-trace them and delete them, as opposed to wiping the entire singularity cache? — Emile Zäkiev, Aug 17 '23 at 15:16

Singularity equivalent to "docker image list"

1 Answers1