Reconsider use of Docker images

[BrianJKoopman]

Historically we published Docker images for so3g so users didn't have to compile spt3g and so3g themselves. ocs (and as a result socs) used the so3g image as a base image to build on. I recently removed this dependency in ocs (see simonsobs/ocs#397), instead installing so3g from PyPI.

Now that that's done I wanted to raise this issue to discuss the need for publishing Docker images with so3g compiled in them. I'm currently also publishing the simonsobs/spt3g images (from this repo.) If we stop publishing so3g images I'd also stop publishing those.

so3g uses the tag from the simonsobs/spt3g image to determine which version of spt3g to use, so that'll have to be reworked if we stop publishing images.

[arahlin]

I'll add that it has long been on my radar to publish spt3g software on PyPI with a more regular release cadence. There are a lot of portability gotchas with a package this complex, so I've been punting on it until it actually became necessary. The discussion here may motivate me moving this up on the to-do list.

[BrianJKoopman]

I'll add that it has long been on my radar to publish spt3g software on PyPI with a more regular release cadence. There are a lot of portability gotchas with a package this complex, so I've been punting on it until it actually became necessary. The discussion here may motivate me moving this up on the to-do list.

Ah, good to know. Do you use the simonsobs/spt3g image at all?

[arahlin]

I'll add that it has long been on my radar to publish spt3g software on PyPI with a more regular release cadence. There are a lot of portability gotchas with a package this complex, so I've been punting on it until it actually became necessary. The discussion here may motivate me moving this up on the to-do list.

Ah, good to know. Do you use the simonsobs/spt3g image at all?

Not that I'm aware of. Most people build the software themselves from the SPT private repo (of which the public CMB-S4/spt3g_software is a subset).