[7.0.0rc1] Mark some "future" test in coordinates as remote_data - #17359
Conversation
These tests (seem to) try to pull remote date because of the not-covered time range, which should be marked as such. Otherwise, Build without remote access (like on Debian package builds) fails.
neutrinoceros
left a comment
There was a problem hiding this comment.
none of these tests are new. It's not immediately obvious to me why this is suddenly needed. Would it be possible to bisect the change so we have a better idea wether it was intended ?
|
Bisection is difficult in my workflow, as I take released tarballs as input for the Debian packaging (and need to adjust local patches to it). Here is the first failure: and this looks to me that it tries to download the data because they are too old. 6.1.5 passes here. Indeed we use a rather old version of astropy-iers-data (0.2024.07.22.00.34.13). |
|
I see. Indeed I don't think we run tests against old versions of astropy-iers-data anywhere (and in fact require the newest version in testing), so it makes sense that we didn't catch this in CI. Do you have a sense why this wasn't seen for previous releases ? |
|
I don't know. I have run the tests for 6.1.5 at almost the same time and didn't observe a failure. One difference may be that in 6.1.5 one additional warning was catched, Reverting to this didn't resolve it, but produced a failure that the specified warning was not raised. I guess the problem is that the IERS_Auto logic changed and this change was not correctly handled in #16187: In 6.1.5, it just raised that warning, but now it instead tried to download an actual file (which fails in my case). Maybe @ayshih could help here. In Debian we need to have all dependencies resolved locally (i.e. no remote connections) and we want to have the packages buildable (incl. tests) during the lifetime of a distribution release; so I need to switch off tests that may become dependent from remote data after some time. |
pllim
left a comment
There was a problem hiding this comment.
Seems fine for now. I also saw similar behavior when moving coordinates examples from Example Gallery into proper docs. We have an issue somewhere to force true "offline" mode in some of these tests but that is a battle for another day. Thanks!
|
p.s. For future reference, please open PR from your fork. Thanks! |
…dinates as remote_data
Oh, yes, sorry, I didn't remember that I have write access :-) I will check this before my next PR. |
…359-on-v7.0.x Backport PR #17359 on branch v7.0.x ([7.0.0rc1] Mark some "future" test in coordinates as remote_data)
|

Description
These tests (seem to) try to pull remote date because of the not-covered time range, which should be marked as such. Otherwise, Build without remote access (like on Debian package builds) fails.