-
-
Notifications
You must be signed in to change notification settings - Fork 427
Refactor JPLSpec/CDMS to bring common code up a level #3456
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
base: main
Are you sure you want to change the base?
Conversation
|
My hacking has hit an awkward position. I wanted to implement a fallback-to-getmolecule approach, but this made me realize that the async-to-sync method prevents returning non-response results and prevents passing arguments directly to _parse_response. Both of these make the workaround a lot more awkward. There are a couple other approaches I could take, but I really want this fallback because of the unreliability of JPLspec and the hinted-at fragility of other services. |
|
What about ditching async to sync? I have my doubts it ever worked in a real async way |
|
yeah, I can get onboard with that. It's a big refactor, but not that hard. That said, I'd need to feel quite inspired / have little on my plate to want to take that on myself. I think it is not the tallest nail right now |
|
(also most of the problems I'm experiencing here are because the SPCAT format is extraordinarily arcane and has dozens of undocumented edge cases....) |
|
Of, I don't mean to refactor the machinery, but feel free to cut the usage of it. We don't use it in the vo backed modules anyway, so it's more like a slow cleanup rather than one big push. |
|
right, good point. OK, I'll think about that - once I get out of qn-parsing hell |
Codecov Report❌ Patch coverage is
Additional details and impacted files@@ Coverage Diff @@
## main #3456 +/- ##
==========================================
+ Coverage 71.48% 71.68% +0.20%
==========================================
Files 234 236 +2
Lines 20096 20226 +130
==========================================
+ Hits 14365 14499 +134
+ Misses 5731 5727 -4 ☔ View full report in Codecov by Sentry. 🚀 New features to boost your workflow:
|
|
I had an LLM write some of the tests to increase coverage. I reviewed those tests, and they look right, but I'm not certain. I can say that they revealed genuine bugs that I had to fix, so that was good. |
|
@keflavich - I believe you pushed to the wrong branch |
|
oh ffs.... you're right. |
|
I'll have to rebase this one after merging #3455 anyway. |
|
As both parent PRs are merged, can you rebase this and squash out iterations as necessary here? |
|
Yes, let me handle that - it will be complex and I will need to remove some things |
5b8ed10 to
203a0a5
Compare
|
This should be ready for review, but I'm less confident than I'd like to be about the rebase. vscode created ridiculous, incomprehensible merge failures in the changelog, so I basically rewrote it from scratch. The rest... most of the conflicts were just import or whitespace errors, so I'll check back through these. |
|
I verified that the doctests whitespace are correct with these commands, which resulted in no diff (to my shock!): |
|
Tests are passing. The OSX failure was unrelated, caused by something in ESA. I'm re-running, but I recommend ignoring that fail even if it re-fails. |
The commit messages below come from individual commits that were squashed into one. A lot of other messages were redundant and manually edited out: factor pseudo-common code into linelists from cdms/jplspec refactor jplspec to not use async machinery refactor to use absolute imports
4843bf0 to
03747d5
Compare
bsipocz
left a comment
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.
Here are some quick review comments.
Big picture: I think we can follow suite of the other modules and remove the not really async methods, and if available have async_job to control the logic to do server side async if supported.
There are some missing docs.
And, it may make sense to have a baseclass for the linelists, that would ensure some API consistency as we go ahead and add more of these.
| linelists | ||
| ^^^^^^^^^ | ||
|
|
||
| - General tools for both CDMS/JPL moved to linelists.core [#3456] |
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.
not sure we need this line as users are not expected to interact with core.
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.
fair enough, but the changelog is also a little bit for devs, no? I'm fine removing this
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.
ok, then we can keep it. I may still need to reformat it before release to be more specific; and thus useful for the devs :)
astroquery/linelists/cdms/core.py
Outdated
| # import configurable items declared in __init__.py | ||
| from astroquery.linelists.cdms import conf | ||
| from astroquery.exceptions import InvalidQueryError, EmptyResponseError | ||
| from ..core import parse_letternumber |
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 don't think we need to use relative imports, stick with absolute ones.
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.
...right. Not sure why I did this.
|
|
||
| - Fix bug in queries for interstellar objects with `MPC.get_observations` and enable queries for "dead" comets [#3474] | ||
|
|
||
| linelists |
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.
if I see correctly, JPLSpec.get_molecule() is a brand new thing. Please mention it above in the linelist.jplspec section.
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.
Please add a section/example about the new get_molecule()
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 on my to-do list for both jplspec and cdms
|
|
||
| return result | ||
|
|
||
| def get_molecule(self, molecule_id, *, cache=True): |
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 needs to be added to the changelog as well as to the narrative docs
| return os.path.join(data_dir, filename) | ||
|
|
||
|
|
||
| @async_to_sync |
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.
Can we remove the async methods as they are not really server async? Or if there is server async available, follow the new API and use the async_job kwargs instead?
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'd rather not do that in this PR
|
|
||
|
|
||
| @async_to_sync | ||
| class JPLSpecClass(BaseQuery): |
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.
It goes beyond this PR, but maybe you want to open an issue about coming up a linelist relevant baseclass? E.g it could behave as a template, e.g. we always have to have a query_lines method, etc.
(but also, this may be an overkill)
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.
maybe, not sure it's needed - so, yeah, beyond this PR
I'm not as sure as I was at the start of this project that there is enough in common, but maybe.
This relies on other open PRs, #3302 and #3455 should be merged before this one, and then this one needs squashing.