sunpy
Merge `sunpy-soar` into core
The objective of this issue is to solicit thoughts on if sunpy-soar is ready to be merged into core.
I would like the focus of this discussion on the maintainability of the code, the relationship with the SOAR and the stability of their API etc.
Merging it into core effectively means we have to fix things that break faster and users probably expect a higher level of reliability.
My personal opinions on this:
I think that it's probably time, sunpy-soar seems to be working reasonably well with minimal maintenance. That being said, I don't know how widely used it is and how likely the people using it are to report bugs and issues to us.
From a code quality perspective, it's got good coverage (94%) and infrastructure matches ours. It should be reasonably easy to graft in the whole commit history to core.
My main concerns are still how responsive the SOAR are to us with issues and how stable their API is, maybe @hayesla or someone else can speak to this more.
I'm currently a +1 on this.
(The other advantage of merging it would be to have one less package to maintain, which is not a negligible amount of effort.)
I think I would vote +1, too. The code shouldn't need much time-critical maintenance. If I remember correctly, in the last years ESA rolled out only one breaking change for sunpy-soar (which was only some minor lowercase-uppercase change). So the system seems to be pretty stable (with solo-epd-loader I did not have any problems at all). Nevertheless, we should try to get in the future some pre-release info from ESA. I'm not sure who would be responsible for it now at their side. If @hayesla does not know, I'm meeting next week with some Solar Orbiter ESA people and could talk to them.
Anyhow, I guess the work for maintaining sunpy-soar as an independent package is bigger than actually bugfixing it if needed.
Anyhow, I guess the work for maintaining
sunpy-soaras an independent package is bigger than actually bugfixing it if needed.
Yeah, we'd want to bug fix it anyway, we'd just do it here rather than there. I guess it just makes it a little more urgent.
I am +0.9 on this.
I think having this in core would force us to more quickly confront any breaking changes happening upstream with the SOAR API. As it stands, it is easier for those changes to go unnoticed (and more work for us to maintain, arguably) if it is in a separate package.
I'm also +1 on this.
The only thing is that we should tidy up some of whats in sunpy_soar. It started to grow (or at least in idea) to do some complex queries using some of the available tables, but that's quite niche, and people who are interested in playing with the tables can do it themselves (i.e. it doesnt need to live in sunpy_soar).
We also have a good relationship with the ESA archive folks, and we could loop them in even more with this.
It would be good to have a list of pre-merge todos, if you have some in your head @hayesla could you start an issue on sunpy-soar?