Fastai2 in Singularity Container

Hi all. Inspired by fast_template, I have just written my first blog post in more than a decade…! In it I described how I built a Singularity container with editable fastai2 installation for multi-user HPC environment, which can be used to follow the part1-v4 course.

I have not been experimenting with and using Singularity containers for very long yet, but if anyone has any question about my post, we can discuss them here : )

My Singularity example def file explained in the blog post can be found here.




Without getting sudo or root permission on a production HPC cluster, I can define and build a Singularity container on a separate cheap cloud instance (where root is available), which can have a pip editable install of fastai2.

The resulting container sif file can be used on the HPC cluster, have native access to GPU CUDA compute, easily retain user/group permissions in the multi-user HPC environment, and have all the necessary software stack dependencies (except NVIDIA GPU driver, which must be present on the HPC host system) without messing up or interfering with other software stacks or environments on the HPC host system.

The editable install residing on the HPC host filesystem means that I can easily upgrade/change the version of fastai2 via git, and users of the Singularity container can get the corresponding version changes ‘live’. This allows a ‘balance’ of having flexibility to experiment with software stacks in a multi-user production HPC environment with native user/group permissions, while reducing the risks of messing things up for everyone (e.g. via undesired root privilege escalation that can happen in Docker). It also means that other users can all re(use) the same container with the same versions of software stack, e.g. for a fastai study group.

My Singularity example def file explained above can be found here.

1 Like

Thanks for your excellent post and blog on creating a fastai2 Singularity container. They are exceptionally well written.

I fooled around with Singularity and your .def file. My conclusions and a .def file adapted to my situation are at

1 Like

Thanks for your kind words re: my blog post : )

Definitely agree with your conclusions, i.e. Docker and its ecosystem (e.g. wide availability of pre-built images) are definitely a better ‘default’ choice for containerisation work, especially if some of its disadvantages can be worked around, or do not matter for your use case. I went with Singularity for my fastai2 container mainly because of the need for HPC multi-user environment constraints.

And thanks also for your correction on my .def file, I have updated it in my repo.