Backports for 0.20.x #2059
Backports for 0.20.x #2059
Conversation
Remove use of setuptools_scm_git_archive
|
Should we backport the couple other things tagged with 0.20.3? |
|
Do we want to make a 0.20.3 or a 0.20.2.post1? |
|
It's just that we have broken tests now; it might be good to backport those fixes as well... |
Change to assert_allclose instead of assert_almost_equal to test small changes as recommended by Numpy's testing docs. This is due to small tolerance changes with PROJ 9.0.1.
These only minimally changed with a shifting of the dashes in the gridlines, but no substantive changes.
|
I don't understand. One fails with |
|
Might be due to different pins on the previous branch? |
|
All versions failing (at least last time) were Matplotlib 3.5.2, which is also passing on other runs. 😬 I also note now that ubuntu 3.8 failed a test after I added my debug output, and it didn't fail last time. Something non-deterministic is going on it seems... |
dopplershift
force-pushed
the
backport-2057
branch
from
0da2a37
to
a3271cd
Compare
|
Oh swell, re-running finally fixed one of them. |
dopplershift
force-pushed
the
backport-2057
branch
from
a3271cd
to
9c3a5a7
Compare
|
I figured it out: PROJ 8 vs. 9 apparently triggers a few minor image changes. There's an ambiguity in solving where you can either get either PROJ 9 and owslib 0.25 or PROJ 8 and owslib 0.26. I don't think I can express just how much I hate software right now. (╯°□°）╯︵ ┻━┻ |
Depending on the values input to Nightshade, the floating point precision could put the range for arccos outside of [-1, 1], which in turn numpy returns as nan's, yielding bad geometries further downstream. This patch clips the arccos calculations to [-1, 1] to guarantee we aren't out of the valid floating point bounds.
|
You are far braver than I to venture into the backporting world ;) I would have taken the easy way out and pushed a |
|
Honestly, the backports have been easy. Figuring out why CI is failing is...so annoying. I share @QuLogic's unease with cutting a release from failing tests... |
Apparently the images change between PROJ 9.0.0 and 9.0.1
dopplershift
force-pushed
the
backport-2057
branch
from
0a6f871
to
50b7399
Compare
|
So apparently it's actually a change produced by PROJ 9.0.1 vs. 9.0.0. On Python 3.7, we can only install PROJ 9.0.0 because the only versions of pyproj that have been recompiled for PROJ 9.0.1 don't support Python 3.7. 😱 Therefore for this branch (and I think it should stay here) I included the PROJ version in the check for an appropriate tolerance. |
|
Strange that didn't come up in #2051. |
|
Not sure why it finally passed, but it did. I've been unable to reproduce the series of failures locally in a VM. Regardless, if someone can merge we can cut 0.20.3! |
|
Lets hope it stays that way once merged too :) @dopplershift, go ahead and make the release. Thanks for doing all that work with CI and backporting! |
|
Note to self: backporting like this makes the autogenerated release notes basically useless. |
Ok, grabbing some bug fixes from 0.20.3 milestone:
This had a few conflicts to take care of.