Integrate into core?

[keflavich]

@mhvk @Jan-Willem @e-koch @jeffjennings were on a conversation about this.

Presently, casa-formats-io is a separate package, and I think the motivations for this are that it's still a bit of an alpha product and we aren't aware of broader use cases. As the NRAO integrates casa-formats-io into next-generation data handling processes, those assumptions will probably both break, and we should integrate CASA table reading into core.

What would that process look like, @astrofrog ?

[astrofrog]

Just to check, do you mean astropy core?

[keflavich]

Yes, exactly.

[astrofrog]

Sorry for the delay, I've had a chance to think about this. A few thoughts and questions:

• The CASA table/image format is not documented anywhere as such, unlike say FITS or VOTable, and the implementation in this casa-formats-io repository is a combination of reverse engineering of the format combined and interpretation of the casacore format. Because of this, it is unlikely (at the moment) to be acceptable for inclusion in astropy core.

• With Python dependencies being well handled these days, what is the downside of having this be its own repository? Other formats such as ASDF do this and it works well. It means you can do quick releases as needed, rather than waiting e.g. for an astropy core release.

• Is it that there would be a preference for this to be under the astropy ecosystem umbrella to ensure long-term maintenance? If so, then perhaps this package could apply to become an astropy coordinated package?

• If there is there interest from NRAO to contribute to the development of casa-formats-io? If so, then having it live as a coordinated package under astropy would be similar to PyVO, where different institutions are contributing to it.

• If there any interest to write a formal spec for the format? I think we discussed this before, but this formal spec could live with the casa-formats-io repository. In the long term, if there is a formal spec, and we implement it in full, then at that point it might be that we could apply for this to become part of astropy.io.

[Jan-Willem]

Our primary goal with casa-formats-io is to replace python-casacore in our prototyping efforts for the next generation of CASA and Pipeline, known as RADPS (Radio Astronomy Data Processing System). I will create an issue on casa-formats-io to outline our requirements and feature requests. We are prepared to contribute developer time to help implement these changes.

In response to some of @astrofrog's bullet points:

• Integrating casa-formats-io into the core is not a priority for us; we prefer having quick releases to address issues as they arise.

• Regarding interest from NRAO to contribute to the development of casa-formats-io: Yes, CASA (NRAO) does have some developer time available for this purpose.

• On the topic of writing a formal specification for the format: Yes, that would be great.

[mhvk]

All makes sense - my suggestion for moving to astropy core was really only once the standard and state had matured, say to the level FITS was when we started astropy. Of course, even then this may remain too niche to support; depends if it becomes the standard for most radio telescopes or not.