Open BrianJKoopman opened 3 months ago
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.
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?
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).
Historically we published Docker images for so3g so users didn't have to compile spt3g and so3g themselves.
ocs
(and as a resultsocs
) used the so3g image as a base image to build on. I recently removed this dependency inocs
(see https://github.com/simonsobs/ocs/pull/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.