[INSTRM-1615] RFC: Consider basing ICS on rubin-env conda/python environment

Relates — Fri, 11 Nov 2022 14:24:34 +0000

The production ICS python environment is currently a conda 3.7 + handful-of-packages thing, as defined in INSTRM-306

The hxActor requires 3.8, because of how nice and reliable the new multiprocessing.shared_memory module was. I have been testing for months with 3.9, figuring that if we update we might as well catch up with the latest stable version.

Rubin has switched to a conda-forge based environment named rubin-env. For the version of DRP that PFS has just switched to, that is rubin-env 3.0.0 (python 3.8). Their current environment is 4.0.0, which is python 3.10 (the current stable version).

Both of those have current cython, astropy, fitsio, psycopg2, etc, and in general are up-to-date, very very much unlike the previous LSST environment.

Promisingly, the hxActor and oneCmd are happily running under something like the following at JHU:

mamba create -n rubin3_ics -c conda-forge rubin-env=3.0.0
conda activate rubin3_ics
mamba install -c conda-forge twisted ply dnspython astroplan
EUPS_PATH=$EUPS_PATH:/software/mhs/products

[ there will be a few more packages needed. pyqt, qt5reactor, fysom (still pip only, grr), etc. Plus Jupyter, etc. Does conda activate --stack work? ]

So, we certainly could base ICS on the Rubin environment. Would that be a good idea? I don't quite know yet: I have been trampled while dancing with this particular elephant before. But I think we can and should look into it.

PFS-JIRA

[INSTRM-1615] RFC: Consider basing ICS on rubin-env conda/python environment