Add support for Python 3.11

[seisman]

Description of proposed changes

Python 3.11 has been released on Oct. 24, 2022, changelog is at docs.python.org/3.11/whatsnew/3.11.html.

Previous PRs for Python 3.10 are #1591 and #1577.

Reminders

• Run make format and make check to make sure the code follows the style guide.
• Add tests for new features or tests that would have caught the bug that you're fixing.
• Add new public functions/methods/classes to doc/api/index.rst.
• Write detailed docstrings for all functions/methods.
• If wrapping a new module, open a 'Wrap new GMT module' issue and submit reasonably-sized PRs.
• If adding new functionality, add an example to docstrings or tutorials.

Slash Commands

You can write slash commands (/command) in the first line of a comment to perform
specific operations. Supported slash commands are:

• /format: automatically format and lint the code
• /test-gmt-dev: run full tests on the latest GMT development version

[weiji14]

Not sure why the mamba install step fails at https://github.com/GenericMappingTools/pygmt/actions/runs/3326717710/jobs/5525427951#step:5:63 without any useful error message, so I tried testing locally:

mamba create --name pygmt python=3.11
mamba activate pygmt
mamba install gmt=6.4.0 numpy=1.23 pandas xarray netCDF4 packaging geopandas ipython build dvc make 'pytest>=6.0' pytest-cov pytest-doctestplus pytest-mpl sphinx-gallery

which also crashed with no error 😅 I think there are some python 3.11 migrations still ongoing (see https://conda-forge.org/status/#python311), so maybe wait for a few more days.

[weiji14]

I figured out why no error messages were raised. It's because of these lines:

pygmt/.github/workflows/ci_tests.yaml

Line 95 in 6149c53

build dvc make pytest>=6.0 \

pygmt/.github/workflows/ci_tests_legacy.yaml

Line 68 in 6149c53

build dvc make pytest>=6.0 \

Should be using 'pytest>=6.0' instead of pytest>=6.0, otherwise the outputs go into a file called =6.0 😅 WIth that, I'm getting:

Encountered problems while solving:
  - package dvc-1.9.0-1 requires _dvc 1.9.0 py37hc8dfbb8_1, but none of the providers can be installed

so need to wait for dvc.

[weiji14]

Seems like dvc is waiting on conda-forge/omegaconf-feedstock#40 (comment), gonna see if it's possible to make omegaconf noarch to unblock this.

Edit: May need to wait for omegaconf>=2.2.4 for Python 3.11 support, see conda-forge/omegaconf-feedstock#42 (comment). Or get noarch builds for dvc at conda-forge/dvc-feedstock#192.

[weiji14]

Yay, so dvc is now noarch 🎉, but mamba is stuck trying to finding a solution satisfying python=3.11 😂. Still need to wait for omegaconf>=2.2.4 I think. The dependency chain is dvc -> hydra-core -> omegaconf, and because omegaconf==2.2.3 on conda-forge is currently pinned to python <3.11, the CI workflows using dvc won't work 😭

Edit: Actually, the solver worked after 27min 😮. Here's the error from https://github.com/GenericMappingTools/pygmt/actions/runs/3625294879/jobs/6113181492#step:5:26:

Encountered problems while solving:
  - package dvc-2.36.0-pyhd8ed1ab_1 requires hydra-core >=1.1.0, but none of the providers can be installed

[weiji14]

The dvc -> hydra-core -> omegaconf dependency chain should be ok now. I think it's the geopandas -> fiona part which still needs some love. Specifically, need to wait for GDAL 3.6 builds of fiona, see conda-forge/fiona-feedstock#203?

[weiji14]

The dvc -> hydra-core -> omegaconf dependency chain should be ok now. I think it's the geopandas -> fiona part which still needs some love.
Encountered problems while solving: - package dvc-2.36.0-pyhd8ed1ab_1 requires hydra-core >=1.1.0, but none of the providers can be installed

Spoke too soon. We actually need hydra-core to relax it's dependency pin to use omegaconf=2.3 to be installable with Python 3.11. Issue being tracked at facebookresearch/hydra#2510.

Do you want to wait, or split this PR into 2 (as was done with Python 3.10) - one for the files that don't use dvc, and one for the CI workflows that use dvc?

[seisman]

Do you want to wait, or split this PR into 2 (as was done with Python 3.10) - one for the files that don't use dvc, and one for the CI workflows that use dvc?

I feel it makes more sense to wait, because we can't say that we support Python 3.11 without running the full tests (which requires dvc).

[maxrjones]

@weiji14 great work getting all those package conflicts cleaned up! 🚀 🎉

[weiji14]

@weiji14 great work getting all those package conflicts cleaned up! rocket tada

Yes, finally! Those dvc dependencies with hard upper pins were painful 🙂 We're at ~2months since Python 3.11 was released so not too bad, about the same as Python 3.10 last year in #1577. I'm hoping that Python 3.12 will be smoother since dvc is noarch now 🙏