Allow retrieval from a previous ESO archive request#1614
Conversation
Codecov Report
@@ Coverage Diff @@
## main #1614 +/- ##
==========================================
- Coverage 61.96% 61.91% -0.05%
==========================================
Files 129 129
Lines 16297 16310 +13
==========================================
Hits 10099 10099
- Misses 6198 6211 +13
Continue to review full report at Codecov.
|
keflavich
left a comment
There was a problem hiding this comment.
This is a great modification. I have a few request:
- small fix to f-string (see inline)
- add a changelog entry (this is important and should be advertised)
- mention the change in the docs
|
Thanks for the feedback @keflavich . Requested changes submitted. |
|
Thanks for the fixes, and sorry about my delay in responding. The present failure is because, in the docs, you've used single-backticks around variable names. If you change those to double-backticks, it should fix the build, then I'm ready to merge. |
|
To save you scrolling through the Travis logs, here are the errors: |
|
@gbrammer This PR is in a pretty good state and was nearly ready to merge. Are you able to do the last little bits of cleanup, and a rebase, so we can get this into astroquery? |
|
@kevlavich I think I have the changes implemented as requested. I'm not sure what the |
|
I've rebased this to get rid of the merge commit, etc. |
|
@keflavich Is there a way I can fix the codecov failures on this PR? |
|
You could add a test for the new functionality. Do you have an idea how you'd do that? |
|
I've rebased this and squashed, we should merge if it's all green. |
Review has been addressed. One review point, about f-string is outdated now, so I have squashed out the commit that addressed it.
|
Thank you @gbrammer! |
Requesting large numbers of datasets from the ESO archive can take a long time to execute and this provides the opportunity to avoid duplicating an earlier request that my have timed out or otherwise broken.
The changes here allow a user to manually specify an ESO Archive request ID in
eso.retrieve_datarather than always sending a new retrieval request. The desiredrequest_idcould either have been generated internally toastroqueryor manually.Here we do check that the specified retrieval URL based in the
request_idis valid and then that the datasets indicated there are consistent with the user-specifieddatasets, but there is currently no reverse checking that the specifieddatasetsare provided inrequest_id.Generally, the user can identify valid
request_ids either from the confirmation emails sent from the archive related to the request or at https://dataportal.eso.org/rh/requests/[USERNAME]/recentRequests.