Skip to content
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

Open
wants to merge 2 commits into
base: main
Choose a base branch
from
Open

Drop Python 3.9 support #2741

wants to merge 2 commits into from

Conversation

djhoese
Copy link
Member

@djhoese djhoese commented Feb 6, 2024

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.

@djhoese djhoese added enhancement code enhancements, features, improvements backwards-incompatibility Causes backwards incompatibility or introduces a deprecation cleanup Code cleanup but otherwise no change in functionality dependencies Pull requests that update a dependency file labels Feb 6, 2024
@djhoese djhoese self-assigned this Feb 6, 2024
@djhoese
Copy link
Member Author

djhoese commented Feb 6, 2024

The remaining unstable environment breakage has been reported here: Unidata/cftime#318

Copy link

codecov bot commented Feb 6, 2024

Codecov Report

All modified and coverable lines are covered by tests ✅

Comparison is base (4877082) 95.88% compared to head (4c73bd6) 95.88%.
Report is 7 commits behind head on main.

Additional details and impacted files
@@            Coverage Diff             @@
##             main    #2741      +/-   ##
==========================================
- Coverage   95.88%   95.88%   -0.01%     
==========================================
  Files         371      371              
  Lines       52825    52824       -1     
==========================================
- Hits        50653    50651       -2     
- Misses       2172     2173       +1     
Flag Coverage Δ
behaviourtests 4.15% <20.00%> (-0.01%) ⬇️
unittests 95.98% <100.00%> (-0.01%) ⬇️

Flags with carried forward coverage won't be shown. Click here to find out more.

☔ View full report in Codecov by Sentry.
📢 Have feedback on the report? Share it here.

@coveralls
Copy link

Pull Request Test Coverage Report for Build 7802697177

  • 0 of 4 (100.0%) changed or added relevant lines in 1 file are covered.
  • No unchanged relevant lines lost coverage.
  • Overall first build on drop-py39 at 95.964%

Totals Coverage Status
Change from base Build 7801990864: 96.0%
Covered Lines: 50523
Relevant Lines: 52648

💛 - Coveralls

Copy link
Member

@sfinkens sfinkens left a 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.

@ameraner
Copy link
Member

ameraner commented Feb 7, 2024

I understand that the fact that EUMETSAT's fcidecomp package (https://anaconda.org/Eumetsat/fcidecomp, and https://gitlab.eumetsat.int/open-source/data-tailor-plugins/fcidecomp/-/tree/2.0.1?ref_type=heads, see also threads on slack) only currently supports only up to py3.9 is going to be a problem after this PR.

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 hdf5plugin)?

@simonrp84
Copy link
Member

I agree with @ameraner, if possible it'd be good to delay the dropping of 3.9 until FCI can be easily supported.

@djhoese
Copy link
Member Author

djhoese commented Feb 7, 2024

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.

@pnuu
Copy link
Member

pnuu commented Feb 7, 2024

I don't have a problem waiting a little longer, but don't all the readers use hdf5plugin right now?

We don't import hdf5plugins in Satpy. It was decided that we shouldn't force the user to one solution, so either import hdf5lugins before importing satpy/xarray/netcdf4/h5netcdf, or installing fcidecomp, by the user is always required.

@djhoese
Copy link
Member Author

djhoese commented Feb 7, 2024

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.

@gerritholl
Copy link
Collaborator

gerritholl commented Feb 7, 2024

I think @gerritholl had shown that fcidecomp doesn't even work with modern numpy versions.

That problem was fixed by EUMETSAT (or their contractor). fcidecomp now works with modern numpy.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
backwards-incompatibility Causes backwards incompatibility or introduces a deprecation cleanup Code cleanup but otherwise no change in functionality dependencies Pull requests that update a dependency file enhancement code enhancements, features, improvements
Projects
None yet
Development

Successfully merging this pull request may close these issues.

None yet

7 participants