The “shared stack” on lsst-dev has been refreshed so that it is now based on the new Conda environment introduced on RFC-664. The new stack can be found at /software/lsstsw/stack_20200220 . It currently contains weekly w_2020_07 of lsst_distrib, and will be updated with new weeklies as they become available. It also contains the following additional package in the Conda environment:
panel
holoviews
hvplot
bokeh
pyviz_comms
fastparquet
numba
datashader
pyct
dask-jobqueue
snappy
geoviews
cx_Oracle
ipdb
As well as git_lfs which must be activated by EUPS (setup git_lfs). Please follow-up to this post with any requests for further packages to be added.
Be aware that this stack does not contain lsst_sims due to SIM-2621. if you need to use lsst_sims, you can continue using the older environment at /software/lsstsw/stack_20191101.
/software/lsstsw/stack will always be a symlink to the latest stack.
I was excited to see cx_Oracle on this list, as it’d be a bit easier to use than the manual eups declarations I’ve been using. But it doesn’t seem to have been installed with access to an actual Oracle client library (which may be proprietary and thus not something one can even get from conda). Can anyone shed any light on how the conda package is supposed to work?
Here’s what I get from trying to run daf_butler's optional Oracle unit tests:
sqlalchemy.exc.DatabaseError: (cx_Oracle.DatabaseError) DPI-1047: Cannot locate a 64-bit Oracle Client library: "libclntsh.so: cannot open shared object file: No such file or directory". See https://oracle.github.io/odpi/doc/installation.html#linux for help
I note there are some Conda channels providing oracle-instantclient, but they haven’t been updated in the better part of four years. In a couple of minutes of searching, I didn’t find a release date for the latest version, so I can’t tell how current they are.
We could also declare instantclient in the shared EUPS stack if that’d be helpful.
Following 864001f51, sims_catUtils no longer works with Astropy 3.2.3, as provided by the 20191101 stack. Updates to this stack have therefore been disabled (but the stack itself will remain in place for the foreseeable future, and you are welcome to continue using it to access old builds).
I’m comparing the shared-stack setup on lsst-dev with the newinstall based binary install on cvmfs from IN2P3. I see a few differences I would like to understand. It would be great if someone could quickly explain them to me.
The loadLSST.bash installed by newinstall has a devtoolset-8 setup in the end. But, I don’t see that on lsst-dev. Is that just because you want people to do it themselves there and be able to swap in different compiler sets?
On our install for w_2020_09 I see a enviroment of :-lsst-scipipe-984c9f7 (set to the hash). On lsst-dev it is just -lsst-scipipe.
It looks like in John’s note (and I followed up on the conda jira issues) we installed the latest conda envs. But on both mine and lsst-dev I see version 4.7 instead of 4.8 (which came out last year).
4.7.12 is the newest miniconda that is available for download. Even if you use miniconda-latest you did not get 4.8 when I tried it 3 weeks ago.
We could have deploy run conda update conda in base after the conda base`packages are installed but last time we tried that things got a bit messy. Maybe it would work better now but I didn’t have any motivation for fiddling with that side of things.
The deployment made for /cvmfs (from sources, using newinstall.sh ) adds a line for enabling the devtoolset used for building each release (e.g. devtoolset-6 or devtoolset-8), if this package is present in the execution host. This is for convenience for the end user so that they don’t have to know which particular devtoolset-X needs to be used with each release of lsst_distrib or lsst_sims and for them to not forget to enable it. This has proven effective and convenient for users.
You attribute to desire what I attribute to laziness…
I think there are a couple of issues here, actually.
I don’t know how this is handled at IN2P3 (I don’t have access to check, as far as I’m aware), but many recipes for automatically enabling devtoolset use /usr/bin/scl_source, which is explicitly tagged with the warning “Don’t use this script outside of SCL scriptlets”. In practice, I’m not aware of its use outside “SCL scriptlets” ever having been a problem, but it wasn’t obvious that it wouldn’t be several years ago when the lsst-dev infrastructure was set up.
It’s convenient to be able to load other software collections at the same time as devtoolset-8 (I personally always use rh-git29, for example). Rather than hard-coding a list of my favourite SCLs into the setup scripts, we wrote a convenient (ish) script that enables users to automatically choose whatever collections they like, and documented it in the Developer Guide.
If I were setting things up again from scratch, I might make different decisions. But I’m not!
The reasons are basically historical: when this system was first deployed, it didn’t use newinstall.sh at all: it just installed everything using EUPS directly. That behaviour led to a bunch of assumptions being baked into the setup script.
A few years back, newinstall.sh got substantially rewritten. At that point, it became impossible (or, at least, more trouble than it was worth) to simply infer the right values to use to bootstrap the EUPS system, so I modified the system to call newinstall.sh. However, I wanted to make these changes as non-disruptive to the existing system as possible (it’s that laziness again…), so I had to override some aspects of the default newinstall.sh behaviour. This is one of them.
Again, if we were doing this from scratch, using 2020-era infrastructure, it probably wouldn’t look like this. But newinstall.sh did not look like it does now back in 2016 when this was put together, and we don’t have resources to substantially rework it.
SIM-2621 hasn’t quite been closed yet, but I believe the issues have been resolved and, as of w_2020_10, lsst_sims is available in /software/lsstsw/stack_20200220.
