This is a pre-RFC to test the waters.
The reality is, we have a lot of issues that originate from the wide range of user environments convolved with a relative brittleness of the stack to third party changes convolved with oh god python. Even in the relatively small LSST-land world, they are a constant source of requests for user support. I do not believe that DM shipping third parties is the right solution - it’s a “and now we have two problems” situation, and if I had the authority to veto it I would.
Initially our approach at SQuaRE was to take the environment as close as possible to distro systems on a small number of OSes and tie into their existing package mechanism (rpms, homebrew, whatever) for user support, and package running environments as VM/containers for users that desire a slower moving “off the shelf” experience.
Aside from the difficulty we had decomposing the build (some of the issues have been resolved, not all) the other thing that happened was that @mjuric did an anaconda-based distribution to help out Sims who are ahead of DM in the curve of user encounter. It is obvious that from the user point of view, this is a highly successful solution - it tends to be familiar to users, it plays well with other popular packages in this space, it’s not an in-house solution (danger Will Robinson) - it’s not even an astronomy ghetto solution, and it presents a single environment irrespective of native OS. Importantly for us, it would also allow us to move the stack build/install process closer to a community standard.
After serious discussion, and in a “least bad choice” spirit, SQuaRE is thinking of RFCing a proposal that we move to anaconda as the only supported environment for distributing the stack.
There are disadvantages/risks. Anaconda is supported as a goodwill/promotional gesture by Continuum Analytics. They don’t have a business model that would allow us preferential treatment as far as I can tell. My own personal could-be-so-so-wrong guess is that anaconda has sufficient legs by now that if CA lost interest, an equivalent community effort would spring up.
Moreover, conda has proven to be a fragile shipping platform on Linux in my preferred mode of letting the dependencies float and we are being forced to mitigate that by various strategies. The OSX experience has been better, and the reality is that OSX is the dominant user-oriented platform. SQuaRE would not have be advocating this solution if the stack was only ever going to run inside a factory, but that’s not the case here, nor do we want it to be. What we know is that we want to be CIing something that is as close as we can get to a user environment - not just their stack environment, all their environment, and anaconda is a good solution for that.
This is not an RFC, but a solicitation of discussion that would allow me to construct a good RFC, capturing the arguments on both sides. I am particularly interested in views from Architecture, since besides SQuaRE they are the team which most gets embroiled in user support issues.
I will also say that I don’t feel the current situation is tenable; if we decide not to go down this route (and trust me, I’m torn) I am going to revert to advocating shipping a containerised runnable environment. However so far the median user seems to not be inclined to go down that way, and also there are disadvantages in terms of appealing to people who already have a productive environment that they want to mix and match (eg astropy).
For the users, it seems like the best option; and I want to be dogfooding what I ship to our users.