ESA Euclid EUCLIDSWRQ-215 get_datalinks_metadata

[jsaizsantos]

Dear Astroquery community:
This is my first PR to this repository. I am a developer working for the Euclid archive at ESAC.

The purpose of this PR is to add a new method get_datalinks_metadata to the Euclid class, to return additional columns on top of the ones returned by the plain get_datalinks method, which is left untouched as it complies with the IVOA standard.

The actual new columns to return are left to the datalinks service of the Euclid archive; currently it is datalabs_path, to be used for Datalabs, but two more will come in a new release of the archive (with no further required change on the Astroquery interface): file_name and hdu_index.

cc @esdc-esac-esa-int

[codecov]

Codecov Report

❌ Patch coverage is 81.81818% with 2 lines in your changes missing coverage. Please review.
✅ Project coverage is 70.75%. Comparing base (b4ccef0) to head (e25b66c).
⚠️ Report is 19 commits behind head on main.

Files with missing lines	Patch %	Lines
astroquery/utils/tap/core.py	71.42%	2 Missing ⚠️

Additional details and impacted files

@@            Coverage Diff             @@
##             main    #3438      +/-   ##
==========================================
+ Coverage   70.72%   70.75%   +0.02%     
==========================================
  Files         232      232              
  Lines       20041    20060      +19     
==========================================
+ Hits        14174    14193      +19     
  Misses       5867     5867              

☔ 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.

[jespinosaar]

Great, thanks @jsaizsantos ! Please let us know if you have further comments, @bsipocz . We are preparing for an internal release at the end of this month, so it would be great if we could have this reviewed and merged by next week.

[bsipocz]

Thanks @jsaizsantos for the PR and welcome to astroquery!

I have some comment for the content here, namely to consider not having the separate method just the new kwarg to get_datalinks. And maybe calling it something else then option, maybe extra_options (I'm not really sold on this idea) or something else that best describes it.

[bsipocz]

Why have this as a separate method rather than just documenting the one needs to have use options='METADATA'? The narrative documentation example below throw me off the track as starting with that one, and based on the method name I expected only metadata rather than it having the same result as using get_datalinks and some extra metadata.

[bsipocz]

options feels very generic; could we be more specific naming this?
Also, I would find it useful to mention what valid values could be for this, from the example below 'METADATA' is one, but how could the user know what else works?

[bsipocz]

In addition, adding a new kwarg is an API change, thus will need to be mentioned in the changelog

[jsaizsantos]

Dear @bsipocz:
I expect all your suggestions have been tackled.
Could you please re-check?

cc @esdc-esac-esa-int

[jespinosaar]

Great, thanks @jsaizsantos ! @bsipocz , just let us know if more changes are needed.

[bsipocz]

I still have one remaining question, namely if we really need the new, thin wrapper method get_datalinks_metadata or could instead just have an example in the docs how anyone could use get_datalinks with the new keyword argument to get the metadata?

[jsaizsantos]

Thanks for replying, @bsipocz.

The request from the mission was to keep the method get_datalinks untouched and working the same (only the new optional argument extra_options had to be added, but the default behavior of this method does not change) and they explicitly asked for a different method returning the extra columns. That's why the new method get_datalinks_metadata doing that.

[bsipocz]

The request from the mission was to keep the method get_datalinks untouched and working the same (only the new optional argument extra_options had to be added, but the default behavior of this method does not change) and they explicitly asked for a different method returning the extra columns. That's why the new method get_datalinks_metadata doing that.

Yeap, the default behaviour stayed the same, but I really urge not to over complicate the user facing API with such thin wrappers. Is this really a blocker for the mission team @jespinosaar to call get_datalinks(..., ..., ..., extra_options='METADATA') instead of get_datalinks_metadata(..., ..., ...)?

[jsaizsantos]

@bsipocz, the mission agrees to remove the new method get_datalinks_metadata and use get_datalinks directly with the new argument. Therefore, I am going to update the PR by removing it and also update the documentation and the changelog.

[jespinosaar]

As @jsaizsantos commented, we discussed with the mission if they really wanted a explicit method or this can be improved in the header docs for the method and/or the main documentation. And we will proceed with the second option. Thanks for your feedback @bsipocz !