Refactor JPLSpec/CDMS to bring common code up a level #3456
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.67% +0.19%
==========================================
Files 234 236 +2
Lines 20096 20228 +132
==========================================
+ Hits 14365 14498 +133
+ Misses 5731 5730 -1 ☔ 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 |
keflavich
force-pushed
the
jplspec_getmolecule
branch
5 times, most recently
from
461478d to
5b8ed10
Compare
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
keflavich
force-pushed
the
jplspec_getmolecule
branch
from
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. |
2 participants
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.