Enable TAP for ESO module

[juanmcloaiza]

Addresses #3138

Changes:

• list_instruments
• list_surveys list_collections
• query_instruments
• query_surveys query_collections
• query_main
• query_apex_quicklooks
• deprecate functions *_surveys(...) in favor of _*collections(...)
• Make sure that ALMA collection is handled properly
• Add type hints to all methods / functions

[pep8speaks]

Hello @juanmcloaiza! Thanks for updating this PR. We checked the lines you've touched for PEP 8 issues, and found:

There are currently no PEP 8 issues detected in this Pull Request. Cheers! 🍻

Comment last updated at 2025-01-17 14:13:03 UTC

[codecov]

Codecov Report

Attention: Patch coverage is 75.59809% with 51 lines in your changes missing coverage. Please review.

Project coverage is 69.58%. Comparing base (3e9ff61) to head (e0bfc14).
Report is 181 commits behind head on main.

Files with missing lines	Patch %	Lines
astroquery/eso/core.py	70.00%	51 Missing ⚠️

Additional details and impacted files

@@            Coverage Diff             @@
##             main    #3141      +/-   ##
==========================================
+ Coverage   68.34%   69.58%   +1.23%     
==========================================
  Files         231      233       +2     
  Lines       19190    19518     +328     
==========================================
+ Hits        13116    13582     +466     
+ Misses       6074     5936     -138     

☔ View full report in Codecov by Sentry.
📢 Have feedback on the report? Share it here.

🚀 New features to boost your workflow:

• ❄ Test Analytics: Detect flaky tests, report on failures, and find test suite problems.

[bsipocz]

One comment for now regarding the deprecation, otherwise is looking good so far (I didn't dive into the details, but had a quick look

[juanmcloaiza]

@bsipocz, hi, I'd like to ask for your feedback regarding deprecated functionality.

This PR's scope is to switch the back-end of the ESO module from WDB to TAP. In doing so, many of the functions will be renamed and their signatures changed (i.e. completely new functions are being written, while others are being removed).

If I understand correctly, astroquery requires that deprecated features are handled via @deprecated decorators. However, in this particular case, the changes are rather large --to some extent a @deprecated decorator would need to be added to the whole ESO module (take this last phrase with a grain of salt, I'm exaggerating).

The question I'd like to ask you as an astroquery maintainer is the following: Would it be admissible for this time to avoid adding deprecated decorators to each of the functions and arguments that we are discontinuing? My impression is that the @deprecated benefits will be small in comparison to the illegibility of the code they'll produce. I would prefer instead to make it very explicit in the documentation that whatever functionality available in past versions may not be available from this version on.

Please let us know what you think (cc @szampier). Thanks in advance for your feedback ;)

[szampier]

return ra is None and dec is None and radius is None or isinstance(ra,...) and isinstance(dec,...) and isinstance(radius, ...)

[juanmcloaiza]

Nice this one, thanks! -- indeed, I don't know why I wrote it that cumbersome.
I made these two extra steps if you don't mind, I find them clearer (also with the parenthesis in the are_all_none line):

are_all_none = (ra is None) and (dec is None) and (radius is None)
are_all_float = isinstance(ra, float) and isinstance(dec, float) and isinstance(radius, float)
is_a_valid_combination = are_all_none or are_all_float

[juanmcloaiza]

@bsipocz , hi, one quick question. Preparing for the future, we are thinking on developing ESO submodules, so that we can query ESO data in the following way:

import astroquery.eso.observations as observations # Current Pull Request
import astroquery.eso.catalogues as catalogues # To be developed in the future

raw_datasets = observations.list_raw_instruments()
# >>> ['MUSE', 'VVV', 'SPHERE', ... ]

# Query raw data:
raw_data = observations.Raw() # Raw data from table dbo.raw
my_astropy_table = raw_data.query(instrument="MUSE")

# Query raw data from an IST:
muse_data = observations.Raw("MUSE") # Raw data from table ist.muse
my_astropy_table = muse_data.query(...)

# Query Phase 3 data:
processed_data = observations.Processed() # Processed data from table ivoa.ObsCore
my_astropy_table = processed_data.query(collections=["MUSE"])

Would this be OK for astroquery standards?

[keflavich]

I'd recommend that some of what you're proposing should be keywords. e.g. observations.list_instruments(processed_status='raw') instead of list_raw_instruments.

If you're going to use observations.Raw("MUSE"), then keep the symmetry and use observations.Processed("MUSE") too.

Other archives generally split their queries by Observation first, Processed State next (e.g., MAST). Is there a structural reason you need to split by processed state first, or could you also support queries that return everything associated with a given observation, then filter from there? If you can support both ways, I think that's better - the average user will not want raw data, so your approach looks possibly better.

[bsipocz]

I would really like to keep the facility name in the name of classes, etc, so while submodules are fine I think it would be better to keep calling them something ESO.

import astroquery.eso.observations as EsoObservations # Current Pull Request
import astroquery.eso.catalogues as EsoCatalogues # To be developed in the future

(I know that mast is an outlier in this sense, and then gemini copied their approach, but I haven't given up on getting the renamed done as outlined in #1748)

[keflavich]

Strongly agree @bsipocz . What you've suggested is a documentation (suggested usage) change, right? i.e., import astroquery.eso.Observations as EsoObservations is how we'd recommend users import the module, but it wouldn't require any code changes?

[bsipocz]

i.e., import astroquery.eso.Observations as EsoObservations is how we'd recommend users import the module, but it wouldn't require any code changes?

No, I would strongly recommend to rename the class itself.

[juanmcloaiza]

Hi @bsipocz and @keflavich , thanks for the attention given to my question. My takeaway is as follows:

• Keep the facility name in the name of classes, etc; submodules are fine --> Cool, thanks! 👍

To quickly answer your questions:

• Is there a structural reason you need to split by processed state first? --> Yes
• Could you also support queries that return everything associated with a given observation? --> No

Not to deviate the discussion, I'm not going into more detailed answers, but am happy to discuss further elsewhere if you're interested. For the rest of your comments, I don't have a clear answer now but they gave important insights as to what external users expect. We will discuss internally and come back with a solution. Thanks a lot! 👍