Repository navigation
Swapping PyEphem moon calculations for astropy's - #167
Conversation
|
I'll revisit this in a few days, on or after June 15, when astropy 1.2 is released and conda installable, and the tests will function appropriately with the astropy>=1.2 requirement. |
|
@bmorris3 - You probably get a green travis after a rebase as the remote builds are already been moved to the allow_failures part |
|
@bsipocz I already rebased, but I'm still getting some failures. They're coming from the same error we dealt with earlier, that the IERS tables are downloading and producing unexpected outputs in the doctests. |
|
@bmorris3 - You need to modify |
|
Thanks @bsipocz for the enormous effort in making this work! |
| time = Time('2012-06-21 03:00:00') | ||
| location = EarthLocation.from_geodetic(-155*u.deg, 19*u.deg, 0*u.m) | ||
|
|
||
| import ephem |
There was a problem hiding this comment.
weird, why is this passed on travis?
There was a problem hiding this comment.
It passes because the tests only run functions that begin with test_* in the name.
These print_pyephem_* functions are used to produce the hard-coded reference values for various calculations used to check astroplan in the tests. Therefore they will stay in the testing code, so that users with PyEphem and double-check/reproduce the reference values if they explicitly run the print_pyephem_* functions directly.
Swapping PyEphem moon calculations for astropy's
This is the beginning of an attempt to remove astroplan's dependence on PyEphem to calculate the moon's position (#35, #111). I say this is the "beginning" of an attempt because there is an issue with
astropy.coordinates.get_moonwhich doesn't allow non-scalar time inputs (astropy/astropy#5069). I've looped over calls toget_moonwith scalar times to produce the expected outputs until fixed. I leftTODOnotes in the functions where the workaround has been used, and if/when this PR gets merged, I'll post an issue to remind us to fix those methods once astropy/astropy#5069 is fixed.Also note that this PR will not pass the CI tests until astropy 1.2 is released (with the new solar system ephemerides features). We will need to require that astroplan uses astropy>=1.2.
On my machine, I'm getting an error when testing with
--remote-datarelating to the IERS downloads, and I can't tell if the error is unique to my machine. The doctests trigger an IERS download which prints a "downloading..." notification to stdout, which results in unexpected output from a line in the docstring example, causing the doctests to fail.