-
-
Notifications
You must be signed in to change notification settings - Fork 390
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
Missions mast #2321
Missions mast #2321
Conversation
Hello @syed-gilani! 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 2022-03-15 20:45:01 UTC |
@syed-gilani - It's probably unrelated to the CI status, but I would suggest rebasing this branch now rather than wait with it until all is ready for review in the PR. Rebase is needed as it includes a lot of unrelated commits, many of those are already merged in from the previous PR, or merge commits. |
Codecov Report
@@ Coverage Diff @@
## main #2321 +/- ##
==========================================
- Coverage 62.98% 62.98% -0.01%
==========================================
Files 131 131
Lines 17059 17067 +8
==========================================
+ Hits 10745 10749 +4
- Misses 6314 6318 +4
📣 Codecov can now indicate which changes are the most critical in Pull Requests. Learn more |
@@ -28,7 +30,7 @@ class MastMissionsClass(MastQueryWithLogin): | |||
""" | |||
MastMissions search class. | |||
|
|||
Class that allows direct programatic access to the MAST search API for a given mission. | |||
Class that allows direct programatic access to retrieve metadata via the MAST search API for a given mission. | |||
""" | |||
|
|||
def __init__(self, *, mission='hst', service='search'): |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Hi @syed-gilani this PR is looking good, one quick request: can you make the optional arguments keyword arguments only like how you did here?
@@ -33,7 +33,7 @@ class MastMissionsClass(MastQueryWithLogin): | |||
Class that allows direct programatic access to retrieve metadata via the MAST search API for a given mission. | |||
""" | |||
|
|||
def __init__(self, *, mission='hst', service='search'): |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
No I would have kept that in, that makes the arguments explicit keyword arguments. We've had things break previously when parameters were fed without explicitly stating which kwarg it was
@jaymedina This PR is ready to be review. Please review when you have a moment. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Hey @syed-gilani this is looking good! Some minor comments, and I'm going thru the checklist to make sure all the features were added - for anything I didn't check off, could you point me to where that is happening in your code?
- Add warning when max number of results are returned (as in mast.catalogues)
Clean up documentation - Fix capitalization and spelling
- Make sure all links to functions work
- Make quotes around arguments etc consistent with rest of the documentation
- Remove redundant text
- Add more information about when a user should choose this service
-
Remove reference to set_service and set_mission functions (they don't exist anymore) - Make clear what happens when invalid kwargs are passed (that they are just ignored)
- Add language in the docstring of services._json_to_table explaining the possible values of col_type and which service(s) they might come from.
- Explore the ignore_value handling in services._json_to_table
- Consider the way the fall through from using idx to col works in services._json_to_table (line 80 in services.py)
- Point user to missions.get_column_list function in missions query doc strings
- Make the order of columns in the astropy table returned by the API consistent
https://mast.stsci.edu/search/docs/#/Hubble%20Search/post_search_hst_api_v0_1_search_post | ||
Any invalid keys are igonerd by the API. | ||
All valid key names can be found using `~astroquery.mast.missions.MastMissionsClass.get_column_list` | ||
function. | ||
For example one can specify the output columns(select_cols) or use other filters(conditions) |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I'm not sure I understand the wording here, is this saying that there are two key names called select_cols
and conditions
?
astroquery/mast/missions.py
Outdated
**kwargs | ||
Mission-specific keyword args. | ||
These can be found in the `service documentation <https://mast.stsci.edu/api/v0/_services.html>`__. | ||
for specific catalogs. For example one can specify the magtype for an HSC search. | ||
Any invalid keys are igonerd by the API. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
typo, ignored
*
Please rebase: - there are many (50+?) commits that are unrelated and cover code that has been merged into Please squash - the back and forth of debugging/check on syntax should be squashed out from the history, keep the actual commits to logical chucks rather than to chronological order of trying things. I think you can address both of these by squashing down to a few commits, or removing all those prior commits and then squashing the rest (both can be done with as an interactive rebase). |
@bsipocz All the items marked for this PR have been reviewed by @jaymedina. Everything is done. The last unchecked item of inconsistent column ordering in the output astropy table is fixed in our API. Line 54 in astroquery.mast.services.py uses keys in json_obj['info'] to add columns to the astropy table. json_obj['info'] returns inconsistent column order in every API call. We fixed that in our git repo and we will deploy the fix to production early next week. I showed that fix to @jaymedina. You can view the incorrect behavior in our app on production using the following curl command. If make the API call multiple times, you would see a different column ordering in the 'info' key of the json response |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I have 2 remaining comment, one about a more transparent handling of kwarg default values, and the other is about the rebase/squash.
And I see that there are still a few unaddressed comments from @jaymedina, please follow-up on those, too.
|
||
Returns | ||
------- | ||
response : `~astropy.table.Table` | ||
""" | ||
|
||
return self._service_api_connection._parse_result(response, verbose, data_key='results') | ||
results = self._service_api_connection._parse_result(response, verbose, data_key='results') | ||
if len(results) >= self.limit: |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This is a great approach, and we should in fact do this, or something similar for all other modules :)
astroquery/mast/missions.py
Outdated
coordinates = criteria.pop('coordinates', None) | ||
objectname = criteria.pop('objectname', None) | ||
radius = criteria.pop('radius', 0.2*u.deg) | ||
self.limit = criteria.pop('limit', 5000) | ||
offset = criteria.pop('offset', 0) | ||
select_cols = criteria.pop('select_cols', []) |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Is there any particular reason that these 6 cannot be pulled out from criteria in the signature? I would think it would be beneficial for the reason to make the defaults visible for the users, and then the 6 lines could be dropped down to 2 in the code itself.
@syed-gilani - you need to rebase on the I'm sure there are people at ST who can help out, but I'm also happy to jump on zoom and do this together step by step, as usually there is just one or two steps that goes wrong and when those are identified the logic of git rebase usually becomes a routine. |
@bsipocz I think I need help. Let me know if you have a few minutes and we can do it together. |
@syed-gilani - sent you a link in email |
@bsipocz You forgot to attach the link in the email. |
8199cee
to
e0a6a4d
Compare
docs/mast/mast.rst
Outdated
@@ -1,3 +1,5 @@ | |||
.. doctest-skip-all |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I'm afraid you need to revert most of these docs changes, they were mostly came from #1975 that enabled the docs being tested.
@bsipocz I reverted that commit and pushed the changes again to the branch. @jaymedina I also made changes based on your feedback. |
@bsipocz @jaymedina We just deployed the column ordering fix to ops. If you run the code examples from docs, you would get the same order of columns in the generated astropy table |
@jaymedina - I you could do a quick review of this. I think most things got addressed and this is ready to go, pending the one doctest failure I see as the warning should be handled for the test. If that's the only issue remaining I'll fix it prior to merge.
|
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Just had one minor comment left over but not a big deal so I will mark this as approved. PR looks great, thanks for your work
@@ -50,6 +50,7 @@ def _json_to_table(json_obj, data_key='data'): | |||
|
|||
# for each item in info, store the type and column name | |||
# for each item in info, type has to be converted from DB data types (SQL server in most cases) | |||
# from missions_mast search service such as varchar, integer, float, boolean etc |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
could you be explicit here and mention that these keywords you are searching with are the cols
?
…Fix once issue 2323 is addressed
OK, so my commit is a very ugly hack to work around #2323, yet keep some ways to show the warning in the example. Once we fix the resource warning, this last commit should be changed to Otherwise, it all passes remote tests, so I go ahead with the merge now. Thank you @syed-gilani and @jaymedina for other review. |
@jaymedina - someone else asked for a release recently, so now I wonder whether you think all the mast related follow-ups are done? It's OK if there are still release blocking things, we can milestone them so I won't forgot about them, I just can't recall anything else than these mission follow-ups. |
There are no |
Sounds great. In that case, I'll try to cut a release next week, we have plenty of new materials in the milestone already. |
PR to fix the following remaining issues for astroquery missions_mast search interface:
. Add warning when max number of results are returned (as in mast.catalogues)
. Fix capitalization and spelling
. Make sure all links to functions work
. Make quotes around arguments etc consistent with rest of the documentation
. Remove redundant text
. Add more information about when a user should choose this service
. Remove reference to set_service and set_mission functions (they don't exist anymore)
. Make clear what happens when invalid kwargs are passed (that they are just ignored)