Drop support for Python <3.11

[mraspaud]

This PR adds support for python 3.13. This was triggered by the rebuild of pyresample for 3.13 in conda forge.

[codecov]

Codecov Report

All modified and coverable lines are covered by tests ✅

Project coverage is 93.97%. Comparing base (7ac934f) to head (eb37fa0).
Report is 18 commits behind head on main.

Additional details and impacted files

@@            Coverage Diff             @@
##             main     #633      +/-   ##
==========================================
+ Coverage   93.96%   93.97%   +0.01%     
==========================================
  Files          86       86              
  Lines       13546    13536      -10     
==========================================
- Hits        12728    12721       -7     
+ Misses        818      815       -3     

Flag	Coverage Δ
unittests	93.97% <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]

coverage: 93.674% (+0.02%) from 93.656%
when pulling eb37fa0 on mraspaud:support-3.13
into f16de0f on pytroll:main.

[mraspaud]

ok so mypy is failing with

pyresample/_compat.py:31: error: Incompatible import of "ArrayLike" (imported name has type "type[ndarray[Any, Any]]", local name has type "UnionType[Buffer, _SupportsArray[dtype[Any]] | _NestedSequence[_SupportsArray[dtype[Any]]] | bool | int | float | complex | str | bytes | _NestedSequence[bool | int | float | complex | str | bytes]]")  [assignment]
pyresample/utils/__init__.py:22: error: Module "collections" does not explicitly export attribute "Mapping"  [attr-defined]

anyone knows what this is about?

[djhoese]

I think I've misused the type ArrayLike in places. I always used it in a "we expect numpy or dask arrays" kind of way, but it is really meant for "we're going to take whatever you give us and make it a numpy array". The pyresample/_compat.py module I think has workarounds for older versions of numpy to reassign ArrayLike = np.ndarray. This shouldn't be needed as I think our minimum version for numpy includes the numpy.typing sub-package. So...I'd say remove pyresample/_compat.py's stuff about DtypeLike and ArrayLike and see if mypy still complains. If this is too much work let me know.

For the second error, change the import to from collections.abc import Mapping and I think that should work. We may have to drop Python 3.9 support if we haven't already.

[mraspaud]

@djhoese @pnuu I think this is ready

[djhoese]

Mypy should do checks based on the oldest supported version of python. So 3.11 in this case?

[mraspaud]

I didn’t know that, fixed, thanks.

[mraspaud]

ah, now mypy is complaining again…

[djhoese]

Maybe just add type ignores for those lines. It is either numpy or the typeshed type definitions for the standard library's hash stuff that doesn't understand that numpy arrays support the buffer interface.

[mraspaud]

Fixed, hopefully

[mraspaud]

Now there is a segfault when building wheels on aarch 64, should I try updating the ubuntu version?

[djhoese]

To be clear it is failing to test the wheels. The building of the wheel seems fine. I wonder, if you haven't already, if we can adopt the changes made here:

storpipfugl/pykdtree#136

[djhoese]

Oh I think we're going to need storpipfugl/pykdtree#136 merged and released so we have a pykdtree ARM wheel with openmp available. Let me see if I can verify openmp linked in those wheels.