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

eJWST prelaunch #2140

Merged
merged 48 commits into from
Nov 26, 2021
Merged

eJWST prelaunch #2140

merged 48 commits into from
Nov 26, 2021

Conversation

jespinosaar
Copy link
Contributor

Dear Astroquery team:

As James Webb Space Telescope (JWST) will be launched on November, we have developed a module to access future ESA JWST Archive using astroquery. I am creating this draft pull request in advance to prepare our module to be integrated in astroquery and inform you about the necessity of merging this pull request at an agreed date with you (before November, I will confirm you a specific date in a few weeks) and, if possible, agree in releasing a new version of astroquery.

This is still ongoing work, no major changes are expected, but you can have a look at this PR if you want and comment anything you think is useful.

Thanks in advance!

Kind regards,

Javier Espinosa

@pep8speaks
Copy link

pep8speaks commented Aug 23, 2021

Hello @jespinosaar! 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 2021-11-26 18:38:01 UTC

@jespinosaar jespinosaar changed the title Ejwst prelaunch eJWST prelaunch Aug 23, 2021
@keflavich
Copy link
Contributor

Thanks for the heads up. I certainly acknowledge the importance of a timely deployment for the JWST archive. Though I suspect we'll have a little while post-launch before there are any data to serve, no?

Is there any redundant code here with the other TAPPlus in astroquery? Can that be reused instead of copied?

@jespinosaar
Copy link
Contributor Author

Hi @keflavich, thanks for your comments. Yes, we will have to wait some time before we have data to serve and, for this reason, we would like to have this PR merged before, to be ready when this happens.

I think I can refactor code that was copied from TAPPlus login window, as we needed a new one with an additional field. I will revise it together with new classes. Thanks!

@jespinosaar
Copy link
Contributor Author

Hi @keflavich !

I have removed the repeated code. Now I can see I have errors in the oldest dependencies, which are not part of my module:

FAILED ../../.tox/py37-test-oldestdeps/lib/python3.7/site-packages/astroquery/simbad/tests/test_simbad.py::test_query_object[m1-None]
FAILED ../../.tox/py37-test-oldestdeps/lib/python3.7/site-packages/astroquery/simbad/tests/test_simbad.py::test_query_object[m [0-9]-True]

I have tried rebasing my branch, but it has not worked. How should I proceed? Thanks in advance!

@keflavich
Copy link
Contributor

Good question, I'm not sure what this indicates. It does indeed seem to be unrelated. I wonder if a rebase is required, and your PR is being tested with some outdated code in other parts of astroquery? But I don't recall making any changes recently that would affect SIMBAD this way.

@bsipocz do you recall any change that would cause this failure? Maybe we were trying to account for a deprecated VOTable function and broke tests... but if so, why didn't CI catch the regression?

@eerovaher
Copy link
Member

I don't know about the broken tests, but I did notice that this pull request would introduce quite a lot of Python2-related code to astroquery, which works against #1870. For example, six has been removed from astroquery and is no longer a direct requirement, but this pull request seems to rely on six quite a lot in astroquery/esa/jwst/token.py.

@jespinosaar
Copy link
Contributor Author

I don't know about the broken tests, but I did notice that this pull request would introduce quite a lot of Python2-related code to astroquery, which works against #1870. For example, six has been removed from astroquery and is no longer a direct requirement, but this pull request seems to rely on six quite a lot in astroquery/esa/jwst/token.py.

astroquery/esa/jwst/token.py file has been removed, as, in the end, it was not necessary anymore. Which other classes do you think we should modify to remove Python2-related code?

Anyway, we still have the issue with SIMBAD...

from astroquery.utils.tap.model.job import Job


class DummyTapHandler(object):
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

In Python 3 classes inherit from object by default.

Suggested change
class DummyTapHandler(object):
class DummyTapHandler:

See also #1879

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Object removed.

if parameters is None:
return len(self.__parameters) == 0
if len(parameters) != len(self.__parameters):
raise Exception("Wrong number of parameters for method '%s'. \
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Raising bare exceptions is considered a bad practice, see for example https://stackoverflow.com/questions/2052390/manually-raising-throwing-an-exception-in-python#24065533
Here it would be much better to raise a ValueError.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I have modified bare exceptions to more focused ones.

Comment on lines 68 to 73
raise Exception("Wrong '%s' parameter value for method '%s'. \
Found: '%s'. Expected: '%s'", (
method_name,
key,
self.__parameters[key],
parameters[key]))
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

The modern best practice is to use f-strings, so as far as I can tell this could be

Suggested change
raise Exception("Wrong '%s' parameter value for method '%s'. \
Found: '%s'. Expected: '%s'", (
method_name,
key,
self.__parameters[key],
parameters[key]))
raise ValueError(f"Wrong {key} parameter value for method {method_name}. "
f"Found: {self.__parameters[key]}. Expected: {parameters[key]}")

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I have replaced most of long strings with f-strings.

@@ -0,0 +1,20 @@
# Licensed under a 3-clause BSD style license - see LICENSE.rst
from __future__ import absolute_import
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This shouldn't be needed in Python3.

Suggested change
from __future__ import absolute_import

See also #1864

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Removed


import os
import tempfile
import unittest
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

The tests shouldn't be using unittest, see #861

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Removed unittests, but MagicMock still needs to be replaced.

Comment on lines 48 to 54
JWST_MAIN_TABLE = conf.JWST_MAIN_TABLE
JWST_OBSERVATION_TABLE = conf.JWST_OBSERVATION_TABLE
JWST_OBS_MEMBER_TABLE = conf.JWST_OBS_MEMBER_TABLE
JWST_MAIN_TABLE_RA = conf.JWST_MAIN_TABLE_RA
JWST_MAIN_TABLE_DEC = conf.JWST_MAIN_TABLE_DEC
JWST_PLANE_TABLE = conf.JWST_PLANE_TABLE
JWST_ARTIFACT_TABLE = conf.JWST_ARTIFACT_TABLE
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Setting up class attributes like this is what the Astroquery API Specification seems to suggest, but the Astropy configuration documentation explicitly warns against this and also provides examples of how config items should be used. See also #544.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Removed following Astropy recommendations.

@jespinosaar
Copy link
Contributor Author

Many thanks for your comments, @eerovaher! I have implemented the requested changes, please let me know if I should modify anything else (e.g. I am working in removing the MagicMock from tests in test_jwsttap.py file, I need to create different mocks providing different results for the same method). I can see we still have the issue with oldest dependencies...
I have a question, JWST launch will be in December, but we would like to have this code merged at the end of November (no data will be accessible, of course). Would it be also possible to have an official astroquery release with this new module?

Thanks!

@bsipocz
Copy link
Member

bsipocz commented Oct 22, 2021

I have a question, JWST launch will be in December, but we would like to have this code merged at the end of November (no data will be accessible, of course). Would it be also possible to have an official astroquery release with this new module?

I'm planning to do a tagged release at the end of October to address the JPL API changes. But also happy to tag one once this is in, before the launch.
(We will also have dev version release on pypi sooner (e.g. can have that with the merge commit), but I agree that this module will be a significant addition that deserves a tagged release that ends up on conda-forge, etc, too.)

@bsipocz
Copy link
Member

bsipocz commented Oct 22, 2021

Re unrelated CI failures: I can't recall seeing this one, but a rebase should certainly resolve the issue.

@bsipocz bsipocz added this to the v0.4.5 milestone Oct 22, 2021
@bsipocz
Copy link
Member

bsipocz commented Oct 22, 2021

Re tests: none of the remote tests seems to work, is there a way to run them?

Also, please let us know if this is ready for review. I suspect it is, but given it's still a draft PR I haven't yet looked into it thoroughly.

Copy link
Member

@bsipocz bsipocz left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Very rough first review. The main point is that I think a lot of the code could be simplified and duplicates removed, especially with omitting the repetition of async and sync jobs with e.g. the usage of the decorator.

"""

JWST_MAIN_TABLE = _config.ConfigItem("jwst.main",
"JWST main table, combination of \
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

no need for linebreak, we don't enforce 80 char long lines, but it can go longer (100 for sure, but up to 120 is acceptable)

astroquery/esa/jwst/core.py Outdated Show resolved Hide resolved
"""
return self.__jwsttap.load_table(table, verbose)

def launch_job(self, query, name=None, output_file=None,
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Use kwarg only arguments for the optional args, it will be cleaner and easier later to add new ones, etc.
This comment is valid for all the methods, but I won't repeat it elsewhere in this review round.

Suggested change
def launch_job(self, query, name=None, output_file=None,
def launch_job(self, query, *, name=None, output_file=None,

JWST TAP plus
=============

@author: Raul Gutierrez-Sanchez
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This seems to be already outdated. I would suggest removing it (we're planning to clean up the rest of the modules, too). The git history tracks code credits more accurately, than just the name and date of the first version of a given file.

(And for the longer term we already have a WIP PR to name people in charge for the different modules)

ARTIFACT_PRODUCT_TYPES = ['info', 'thumbnail', 'auxiliary', 'science',
'preview']
INSTRUMENT_NAMES = ['NIRISS', 'NIRSPEC', 'NIRCAM', 'MIRI', 'FGS']
TARGET_RESOLVERS = ['ALL', 'SIMBAD', 'NED', 'VIZIER']
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I love how this module relies on the other parts of the library 🎉

f"{filter_name_cond}"
f"{props_id_cond}"
f"ORDER BY dist ASC")
print(query)
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

remove the prints

-------
The job results (astropy.table).
"""
return self.__query_region(coordinate, radius, width, height,
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

why is this necessary? why isn't __query_region is `query_region``?

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Same comment above, we can reduce the methods and use just one "query_region" with a boolean parameter async with False as default value to trigger the job synchronously or asynchronously (as it is already done in ESA HST module), instead of using async_to_sync class decorator. What do you think @bsipocz ?

@@ -0,0 +1,750 @@
.. doctest-skip-all
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

we do support doctesting narrative docs with remote-data, please consider using it (though without data it's probably not yet super relevant here)

return mp


class TestData(unittest.TestCase):
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

it would be nicer to not use unittest, but be pure pytest only, but this won't be a blocker

@jespinosaar
Copy link
Contributor Author

Thanks for the review @bsipocz ! I am implementing these changes and simplifying the code, I will let you know when it is ready.
Given that we want to merge it by the end of November (thanks for the possibility of having a tagged release), I think this is ready to review, so I will change it to PR.
Regarding the remote tests, I am going to remove them. They are failing because I have implemented dummy URLs, we do not want our operational URL to become public until we empty our database prior to launch. But, in any case, as it will be empty, the remote tests will still fail, so we will include them in further updates, what do you think?
Finally, I will rebase the code in the next update, let's see if it is solved...

@jespinosaar jespinosaar marked this pull request as ready for review October 25, 2021 15:19
@keflavich
Copy link
Contributor

@jespinosaar rather than delete the tests, mark them as "expected failures" (xfail) with an explanation that they should start passing when the database goes online.

@jespinosaar
Copy link
Contributor Author

@jespinosaar rather than delete the tests, mark them as "expected failures" (xfail) with an explanation that they should start passing when the database goes online.

The point is that, as the observations appearing in those tests will be removed new ones will be ingested, they are going to fail until we modify them, so I see no reason to keep them, at least, until we have a basic set of observations and files to reference the tests. What do you think @keflavich ?

@keflavich
Copy link
Contributor

Right, ok, if the tests will never pass as written, it makes sense to remove them.

@bsipocz
Copy link
Member

bsipocz commented Oct 25, 2021

The point is that, as the observations appearing in those tests will be removed new ones will be ingested, they are going to fail until we modify them, so I see no reason to keep them, at least, until we have a basic set of observations and files to reference the tests. What do you think @keflavich ?

this case I think it's fine to remove the current remote tests. If you currently have some simulated data in the archive, etc, I think it would still be preferable to have the tests using those, just to make sure the module works as expected. If the archive is totally empty and real data is expected to be very different, then remove is the only way ahead.

@jespinosaar
Copy link
Contributor Author

jespinosaar commented Nov 26, 2021

Thanks a lot for your help on this @bsipocz and @eerovaher ! Well, we are progressing!

I think I can solve this error, as this is now an assertion in one of the messages. I have splitted the test_query_target test in two parts, the first one (test_query_target_errors) with the errors and the second one (test_query_target) with the correct inputs. The first test is working with your fix, but the second one is trying to connect to internet... I have commented this second test, I think I should find a less complex way of testing this method.

@bsipocz. I can upload this fix now, what do you think?

@bsipocz
Copy link
Member

bsipocz commented Nov 26, 2021

@jespinosaar - yes, please go ahead, I got side tracked into some cleanup tasks while we were waiting on CI :)

dummyTapHandler.check_call('launch_job', parameters)
assert 'This target name cannot be determined with this resolver: VIZIER' in err.value.args[0]

# def test_query_target(self):
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Please do rather delete it than comment out, unless we're putting this back in once the remote tests are added with the functional archive

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Ok, I am going to remove it.

@codecov
Copy link

codecov bot commented Nov 26, 2021

Codecov Report

Merging #2140 (c84884e) into main (0833f63) will increase coverage by 0.29%.
The diff coverage is 69.80%.

Impacted file tree graph

@@            Coverage Diff             @@
##             main    #2140      +/-   ##
==========================================
+ Coverage   61.90%   62.19%   +0.29%     
==========================================
  Files         129      131       +2     
  Lines       16310    16777     +467     
==========================================
+ Hits        10097    10435     +338     
- Misses       6213     6342     +129     
Impacted Files Coverage Δ
astroquery/esa/jwst/core.py 69.67% <69.67%> (ø)
astroquery/esa/jwst/data_access.py 75.00% <75.00%> (ø)
astroquery/utils/tap/core.py 41.61% <0.00%> (+0.19%) ⬆️
astroquery/simbad/core.py 90.84% <0.00%> (+1.11%) ⬆️
astroquery/utils/tap/taputils.py 79.54% <0.00%> (+5.68%) ⬆️

Continue to review full report at Codecov.

Legend - Click here to learn more
Δ = absolute <relative> (impact), ø = not affected, ? = missing data
Powered by Codecov. Last update 0833f63...c84884e. Read the comment docs.

@jespinosaar
Copy link
Contributor Author

Ok, now it seems everything is finally working!

@bsipocz
Copy link
Member

bsipocz commented Nov 26, 2021

I've double-checked all the modules this uses, and run the remotes, too. test_query_target_error fails if I run the tests remotely, but it's OK as it's related to the dummy URL. So let's go ahead and merge!

@bsipocz bsipocz merged commit ce8cc52 into astropy:main Nov 26, 2021
@bsipocz
Copy link
Member

bsipocz commented Nov 26, 2021

Thank you @jespinosaar and everyone else involved!

@jespinosaar
Copy link
Contributor Author

Many thanks to everyone for your cooperation and support!! See you when we update the URL and release eJWST!

@saimn
Copy link
Contributor

saimn commented Nov 27, 2021

ideally, we should keep the module level tests separate, they should run in separate contexts. Not sure whether that's easily possible with pytest. @saimn would know I think.

@bsipocz - Unless you run tests for each modules in a separate process I don't think there is an easy solution.

@jespinosaar jespinosaar deleted the ejwst-prelaunch branch December 3, 2021 09:58
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

Successfully merging this pull request may close these issues.

None yet

7 participants