Workshop: Integration options for Astropy within the LSST software stack

Data Management DM Notifications
#1

We are currently investigating how the Astropy software could be integrated into the LSST software system. To aid this discussion we are holding a meeting between interested LSST developers and Astropy developers at the University of Washington on Saturday March 26th and Sunday March 27th. We aim to finish around 3pm on the Sunday.

Details on the current investigation by LSST are on Github.

Please let me know if you are interested in attending. The weekend has been selected because this allows us to maximize the number of astropy developers who can attend as it immediately follows the Python in Astronomy meeting.

#2

As discussed at


there are multiple integration options. Do we have a set of reasonable
criteria (e.g.cost, schedule, maintainability, robustness) that will be
considered when making this decision? Are there any reasonable
guesses for how robust is Astropy project itself (e.g. is it likely to
exist and be relevant 10 years from now)?

#3

Our timeline for coming up with a plan is end of April. The motivations are:

  • Does adopting Astropy make us more efficient at coding and let us focus on the LSST-specific issues without having to support general packages? Will we be able to do more for less?
  • Will the learning curve be lower for new developers if we use commonly accepted Python codebases?
  • Would we see broader adoption in the community for our software if they were based on Astropy?
  • Would Level 3 adoption be significantly easier and more popular if Astropy-compatible APIs were available?
  • If we publish some of our packages as Astropy affiliated packages (which by definition means we use astropy interfaces internally) would this encourage more contributions from external developers/scientists?

As for longevity, JWST are entirely based on Astropy so there is a clear support pathway for at least 10 years. The code is BSD-licensed and open source so will not disappear at that time. It also has a huge mindshare in the general astronomy community.

My understanding is that at minimum only option 1 can be justified by MREFC funding. Provision of Astropy-compatible APIs could be justified as part of the general Level 3 design (L3 does not mandate that we just use Level 2 codebase).

#4

I will be at the Python in Astronomy meeting, and will attend the astropy integration meeting.

#5

I am planning on coming, just to the LSST-Astropy meeting.

#6

I will be attending the LSST-AstroPy meeting, but I’ll be at UW from the previous Wednesday afternoon for DRP-AP planning discussions.

#7

I am not sure I can be there in person, but I will try to participate remotely for at least some of the time.

#8

Same here (though I may not be able to attend the whole integration meeting)