Adopt NEP29 - drop support for Python 3.6 and NumPy 1.16

Originally posted at https://github.com/GenericMappingTools/pygmt/issues/644#issue-716952700, but updated slightly

Just bringing up the topic of whether we should follow NEP 29 — Recommend Python and Numpy version support as a community policy standard as noted before in #340 (comment). This would mean dropping support for Python 3.6.

In practice, we’ll need to follow in the footsteps of our dependent packages:

• pandas 1.2 dropped Python 3.6 at pandas-dev/pandas#35214
• xarray is less aggressive, they’re thinking about it at pydata/xarray#4179

Some options we can take are:

• Agressive option - Let PyGMT v0.2.x be the last version series to support Python 3.6, and state that PyGMT v0.3.0 requires Python 3.7 or newer.
• Less aggressive option - Still support Python 3.6 for PyGMT v0.3.0 (but maybe drop it from our test suite entirely to save on CI resources).

---

Does it mean that users cannot install pygmt via pip install pygmt or conda install pygmt if they’re still using Python 3.6? Or they can still install it, but there is no guarantee that all PyGMT functionalities work well with Python 3.6?

It will be quite hard to support four minor versions of Python (3.6, 3.7, 3.8, 3.9), especially for the conda packages where there is a separate build for each one (unless we can work out how to get a ‘noarch’ build). We could still allow pip install pygmt Python 3.6 (with no support guarantees, i.e. no CI checks), but it will become a maintenance burden when our dependency packages (numpy, pandas, xarray) move on.

There’s no rush to do all this, since Python 3.9 is just released, and there are some libraries still to catch up. Even matplotlib (who has more maintainers) is dropping Python 3.6 for their v3.4 (see https://github.com/matplotlib/matplotlib/pull/17662) so it’s worth thinking about following NEP 29 for PyGMT v0.3.0.

_Originally posted by @weiji14 in https://github.com/GenericMappingTools/pygmt/issues/644#issuecomment-705376657_

Are you willing to help implement and maintain this feature? Yes

[seisman]

For the pip case, we could strictly enforce Python 3.6+ (or 3.7+ if we adopt NEP29) via a python_requires setting

That makes sense. I once thought these lines define the minimum supported Python version.

https://github.com/GenericMappingTools/pygmt/blob/7e7da78c773c280d2d9c6724c79ce8b41f6532b0/setup.py#L31-L34

Then I’m in favor of the less aggressive option. We only test Python 3.7-3.9, but allow users run pygmt in old Python versions, although there is no guarantee that pygmt will work as expected.

[seisman]

is there a chance we could setup PyGMT to be no-arch

It looks promising.

The act of adopting NEP29 becomes pretty irrelevant (from PyGMT’s point of view), as people would just be forced to update to a newer Python/NumPy version when the time comes.

Dropping Python 3.6 (or any other old Python versions) means that we don’t have to run CI jobs for old Python versions, and we can use some new Python features which are only available in new Python versions. So we still need to adopt NEP29 or less aggressive.