Migrate from NEP 029 to SPEC 0

[seisman]

The NEP 029 page has a note says:

This NEP is superseded by the scientific python ecosystem coordination guideline SPEC 0 — Minimum Supported Versions.

I haven't read SPEC 0 carefully, but I think we should migrate from NEP 029 to SPEC 0.

[seisman]

OK, reading more about NEP 29 and SPEC 0.

Here is what NEP 29 recommends:

When a project releases a new major or minor version, we recommend that they support at least all minor versions of Python introduced and released in the prior 42 months from the anticipated release date with a minimum of 2 minor versions of Python, and all minor versions of NumPy released in the prior 24 months from the anticipated release date with a minimum of 3 minor versions of NumPy.

Here is what SPEC 0 recommends:

Specifically, we recommend that:

1. Support for Python versions be dropped 3 years after their initial release.
2. Support for core package dependencies be dropped 2 years after their initial release.

They're similar but with some differences:

1. 42 months vs 36 months support for Python versions
2. SPEC 0 is applied to all core package dependencies while NEP 29 is only applied to NumPy.

If we follow SPEC 0, then currently the minimum supported versions will be:

1. Python>=3.10 (NEP 29 recommends Python>=3.9)
2. NumPy>=1.22.0
3. pandas>=1.4.0
4. xarray>=0.21.0

[weiji14]

Python>=3.10 (NEP 29 recommends Python>=3.9)

Looking at the PyPI download stats at https://pypistats.org/packages/pygmt, it seems like Python 3.9 usage is hovering at about 10-30% in the past 3 months, so not an insignificant fraction. Python 3.10 does seem to be the highest at >50% usually.

pandas>=1.4.0

We're going to pin to pandas>=1.2.0 as discussed at #2729 (comment) to ease the implementation of GMT_DATASET. I can also see this more aggressive pin being helpful for #2800, as we'll drop pandas=1.5.x on or after 2024-09-18, and using pandas>=2.0 would ease some implementations of the Arrow integration.

Otherwise, no strong opinions on moving to SPEC 0, and if most of us agree, we can probably move on to implementing the minimum pins. That said, I would maybe suggest that we delay implementation of this to PyGMT v0.12.0, to have a bit of a transition period?

[seisman]

That said, I would maybe suggest that we delay implementation of this to PyGMT v0.12.0, to have a bit of a transition period?

Sounds reasonable.

[seisman]

Here are a few points in my mind:

• Adopt SPEC 0: Since SPEC 0 is already endorsed by NumPy and xarray, we should also adopt SPEC 0 Adopt SPEC 0 policy and drop NEP 29 policy #3037
• Drop Python 3.9 support following SPEC 0 schedule SPEC 0: Set minimum supported version to Python 3.10+ #3039
• Following SPEC 0, we should pin all core dependencies, i.e., numpy>=1.23, xarray>=2022.3.0 and pandas>=1.5.0 SPEC 0: Set minimum supported versions to pandas>=1.5 and xarray>=2022.03 #3043
• To avoid too much maintenance burden, we should only pin them in as few files as possible, i.e., pyproject.toml, requirements.txt, environment.yml, compatibility table and .github/workflows/ci_tests.yaml
• Now we have three core packages to be pinned. We need to think about how to better document them in the compatibility table SPEC 0: Set minimum supported versions to pandas>=1.5 and xarray>=2022.03 #3043

[weiji14]

IPython is also listed at https://scientific-python.org/specs/spec-0000/, and is marked as an optional dependency of PyGMT here:

pygmt/pyproject.toml

Line 46 in 4b7cb2a

"ipython",

Do we need to pin to a minimum version of IPython too? If so, we should be on ipython>=8.0.0 as of early Feb 2024.

[seisman]

IPython is also listed at https://scientific-python.org/specs/spec-0000/, and is marked as an optional dependency of PyGMT here:

pygmt/pyproject.toml

Line 46 in 4b7cb2a

"ipython",

Do we need to pin to a minimum version of IPython too? If so, we should be on ipython>=8.0.0 as of early Feb 2024.

I prefer not to pin IPython since it's not heavily used by PyGMT.

[weiji14]

I prefer not to pin IPython since it's not heavily used by PyGMT.

Ok let's go with not pinning IPython then, less work having to update the minimum pin every release.