An important part of the workflow for (some) Science Pipelines (and perhaps other?) developers is the "shared stack" available on the lsst-dev system. For details on use, see the Developer Guide and this post on clo.
As it stands now, the stack is generated by the nightly Buildbot run and tagged to match (bXXXX). Over time, it has accumulated a large number of tags, which make it extremely slow to use. (This is likely an artefact of EUPS implementation, but fixing it is outside the scope of this RFC.) Further, since the recent switch to Miniconda, it doesn't provide a full Anaconda installation and hence is lacking tools that developers expect (notably IPython). This second problem is not insurmountable, but it adds overhead and confusion, particularly to new users (see repeated discussions in the HipChat Data Management room over the last several weeks). Finally, because of the way tags are applied to the Buildbot products, although the regular bXXXX tags are applied to this stack, the (arguably) more significant tags identifying weekly releases (w_YYYY_WW) are not.
The clo post linked above suggests a couple of alternative ways an end user might set up a stack which avoid some of the slowdowns inherent in the above. However, the change to Miniconda broke those options (
DM-5021): it's possible to workaround by editing some scripts, but again, this is not the experience we want to be providing for developers.
Following discussions at the JTM, it was agreed that SQuaRE will not be supporting the shared stack on lsst-dev, at least through the short X16 cycle. This will be taken on by Science Pipelines with a shoestring time allocation.
The aim of this RFC is to establish what the Science Pipelines team can do to make developers' time as productive and stress-free as possible in the near term. You are invited to supply your suggestions and requirements.
Here's my zeroth-order proposal to give you something to shoot at. Assuming:
- We can break the degeneracy between the Buildbot stack and that provided for use by end users, on the basis that changes as required by Buildbot or the release process should not impact on the stack being used for development.
- Except on very rare occasions, developers rarely have to resort to arbitrary Buildbot tags to diagnose problems. Therefore, providing all of these outside the lsstsw stack is unnecessary: just making weeklies and other special tags available should be adequate.
I suggest using eups distrib to install a new version of the stack which is rooted outside the ~lsstsw tree and telling developers to use this. This stack will include enough Anaconda (or Miniconda) packages to ensure end users can run IPython or any other services they need. A simple script run from cron, or equivalent, will regularly check the sw.lsstcorp.org server and install any new weeklies into this shared stack. Experts can fall back to the ~lsstsw stack when required for debugging purposes; others can forget it exists.
- Which systems other than lsst-dev is the shared stack accessed from? Is there a downside to having it eups distrib install ed on each of those systems independently, or do they need to share some common networked filesystem?
- Is there are requirement for end users to not simply be able to use the stack but be able to write to it (to add new packages, tags, etc)?
- Is a shared stack of this form actually necessary and useful to developers at a level that makes it worth dedicating resources?
- ... others?