-
Notifications
You must be signed in to change notification settings - Fork 293
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
Drop Python 3.9 support #2741
Drop Python 3.9 support #2741
Conversation
The remaining unstable environment breakage has been reported here: Unidata/cftime#318 |
Codecov ReportAll modified and coverable lines are covered by tests ✅
Additional details and impacted files@@ Coverage Diff @@
## main #2741 +/- ##
==========================================
- Coverage 95.88% 95.88% -0.01%
==========================================
Files 371 371
Lines 52835 52824 -11
==========================================
- Hits 50663 50651 -12
- Misses 2172 2173 +1
Flags with carried forward coverage won't be shown. Click here to find out more. ☔ View full report in Codecov by Sentry. |
Pull Request Test Coverage Report for Build 7802697177
💛 - Coveralls |
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.
LGTM, thanks! Also for sharing that nice table.
I understand that the fact that EUMETSAT's Considering that FCI will go pre-operational soon, and satpy will get a lot of attention in the next months because of this, is it an option to wait a bit more for dropping 3.9? EUM "promised" an update in May, but maybe with a little more pressure (e.g. at the OPSWG in March) this could be accelerated. I fully understand that it's highly annoying to wait for updates for a package that is not maintained properly, but considering this special phase with an update of a major met satellite, maybe it's worth considering. If this is not possible/too painful, maybe we should consider writing a docs page for possible workarounds (manual installation from Pytroll's fcidecomp fork, or |
I agree with @ameraner, if possible it'd be good to delay the dropping of 3.9 until FCI can be easily supported. |
I don't have a problem waiting a little longer, but don't all the readers use hdf5plugin right now? I think @gerritholl had shown that fcidecomp doesn't even work with modern numpy versions. |
We don't import |
Ah ok. So not as strict/severe of a case then. Still, if fcidecomp doesn't work with modern numpy then users won't be able to create a new python environment that works with fcidecomp anyway. How do we anticipate people wanting to process FCI data will create their python environments? If they don't specify a specific Python version then they're going to get Python 3.11 or 3.12 as it is. If they are told to install Python 3.9 (or less) then they'll get an older version of Satpy that is compatible with that. So maybe the question is if the newest FCI changes (composites, L2, etc) are requested...eh OK we'll wait. |
That problem was fixed by EUMETSAT (or their contractor). fcidecomp now works with modern numpy. |
Following the guidance of:
https://scientific-python.org/specs/spec-0000/
This PR drops Python 3.9 support and adjusts CI, pre-commit, and readthedocs to use newer versions of Python. This means the currently supported versions of Python will be 3.10, 3.11, and 3.12.
CC @pytroll/satpy-core I've asked for reviews from some of you, but I think as long as there are no complaints this should be a simple agreement and merge.