Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Move astroquery_utils upstream to astroquery #297

Closed
stscicrawford opened this issue Mar 27, 2019 · 14 comments
Closed

Move astroquery_utils upstream to astroquery #297

stscicrawford opened this issue Mar 27, 2019 · 14 comments

Comments

@stscicrawford
Copy link

stscicrawford commented Mar 27, 2019

The code in astroquery_utils.py should be moved upstream to astroquery to make them generally available. It would be very useful to make retrieve_observation available to everyone. It also might make sense to enable it to work well on AWS as well to pull the files from the right place easily.

cc @ceb8 @mdlpstsci

@pllim
Copy link
Contributor

pllim commented Mar 27, 2019

cc @bsipocz and @keflavich as they are astroquery maintainers, for their information only.

@bsipocz
Copy link

bsipocz commented Mar 27, 2019

I'm not sure what this mean or involved, but sure if you say so :)

@pllim
Copy link
Contributor

pllim commented Feb 15, 2024

Huh, it is closed but I don't see any linked PR. Did this happen?

@s-goldman
Copy link
Collaborator

@pllim Ahh sorry, I think I mis-interpreted the request at first glance, but I should have added a comment. Either way, I think this should be an astroquery issue rather than a drizzlepac issue.

@pllim
Copy link
Contributor

pllim commented Feb 15, 2024

Was there an astroquery issue opened?

@s-goldman
Copy link
Collaborator

It doesn't look like it. I can create a new issue with the above information.

@bsipocz
Copy link

bsipocz commented Feb 15, 2024

Why should it be an astroquery issue? I mean you propose to move some tools from drizzlepac upstream to astroquery, that's an issue here unless the utils are seeked out by astroquery.

@s-goldman
Copy link
Collaborator

@bsipocz we are not requesting this on the drizzlepac side. This looks like a comment from a previous user, I'm just trying to close some old tickets. If you think it is useful, feel free to add this functionality to astroquery, if not, feel free to close the ticket. This is not something that we have the bandwidth to implement.

@bsipocz
Copy link

bsipocz commented Feb 15, 2024

We certainly don't have the bandwidth to pull stuff like this out from downstream packages. The original issue tagged ST developers to make the move, I assume in support of the mast module in astroquery. If that's still the plan, then sure, otherwise I don't see how a MAST archive specific functionality is generally useful upstream.

@mdlpstsci
Copy link
Collaborator

There is a single function in the astroquery_utils.py module, retrieve_observation(), which was written as a convenience utility while working on the Hubble Advanced Products project. It is very HST-data centric (e.g., ipppssoot), and it allows for the download of many files at once. Our former manager thought this would be a useful utility to generalize, but that remains to be seen!

@mdlpstsci
Copy link
Collaborator

mdlpstsci commented Feb 15, 2024

IMHO I would just close this ticket as there have not been requests regarding this functionality outside of our project. There would be real work involved to create a generalized version of this utility. I am not saying it would not be useful, but I am saying that this issue looks like an almost solution looking for a problem.

@bsipocz
Copy link

bsipocz commented Feb 15, 2024

Exactly. Thanks @mdlpstsci for the explanation. That would point towards this still being an ST-related issue rather than an astroquery one, so I don't think astropy/astroquery#2950 is the right one to track it. (I also don't like keeping irrelevant issues open as it's more than unlikely that a random astroquery developer will address that one)

@bsipocz
Copy link

bsipocz commented Feb 15, 2024

More and more of our other modules are moving towards using VO backends, and we try to move generalized utilities (e.g. for download) into pyvo, so I agree with the above that generalizing this functionality may not be relevant for any of the parties involved.

@pllim
Copy link
Contributor

pllim commented Feb 15, 2024

Sounds reasonable, especially given the original requester no longer works at STScI. Thanks, all!

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

5 participants