-
Notifications
You must be signed in to change notification settings - Fork 367
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
MNT: drop py39 support and bump min package versions #2380
Conversation
OWSlib 0.26 doesn't play with PyProj 3.3. So bumped OWSlib further to 0.27. geopython/OWSLib#823 |
|
||
|
||
@pytest.mark.natural_earth | ||
@pytest.mark.mpl_image_compare( | ||
filename="igh_land.png", tolerance=0.5 if _MPL_36 else 3.6) | ||
filename="igh_land.png", tolerance=0.5 if _MPL_37 else 3.6) |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
We did this last time too, based on failures in the min version test. I'm starting to think maybe it's not the mpl version making the difference. I don't think I want to start digging into that today though.
environment.yml
Outdated
- pyshp>=2.3 | ||
- pyproj>=3.3.1 | ||
- packaging>=20 |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
=21 to be consistent with pyproject.toml
Can also bump ruff target setting to py310 at: https://github.com/rcomer/cartopy/blob/14beb1bb64aac3b1b1a2852cd9918961e9179ca1/pyproject.toml#L101 |
Maybe drop py39 too from CIBW_BUILD at cartopy/.github/workflows/release.yml Line 93 in 14beb1b
|
Thanks for picking those up @lgolston! Now fixed. |
I think we can actually do even better and just remove |
Rationale
According to the NEP29 Support Table we should now be supporting Python 3.10+ and Numpy 1.23+. SPEC0 says we should support Matplotlib 3.6+ and Scipy 1.9+. For other packages I tried to go for something that is a little older than 2 years. This is more lenient than for the core packages considered by SPEC0, but some of them have pretty erratic release frequencies and it just seemed simpler to go for 2 years+ than try to decide how much less than 2 years is reasonable.
Implications