dropping 3.6 and a few other things

[jarrodmillman]

Now that it looks like NumPy will officially drop Python 3.6 for 1.20, I think it would be nice if other important libraries get on the same page. Pandas and Matplotlib have already dropped 3.6. I am thinking about dropping 3.6 for the next NetworkX release. It would be nice if scikit-image also did so.

So I took a look to see if I could tell whether you had decided to drop 3.6 yet and I noticed that

1. you don't test 3.8 on travis
2. you don't list support for 3.8 in setup.py (see update trove classifiers and tests for Python 3.9 + fix pytest config #5052)
3. your badges on your README say that the forum resource not found and codecov is 0%.
4. it looks like you have not yet dropped support for 3.6. (see [WIP] Drop python 3.6 from the build matrix #5046)

I assume the travis issue is b/c you are planning on dropping it.

Would you consider dropping 3.6 now? Having numpy, pandas, matplotlib, networkx, and scikit-image on the same page would be nice and maybe that would motivate scipy and scikit-learn to do the same.

[hmaarrfk]

Many of the core devs were active on the discussion to drop Numpy 1.20 from 3.6.

I think there are many things we need to do to release a wheel for 0.18 and I don't think we should slow it down for any kind of hiccups.

The omission of python 3.8 was an oversight, and we are working on fixing it in
#5054

Once we have the infrastructure for 3.8 setup, my goal is the following:

1. Bump all builds configuration from 3.6 -> 3.7, 3.7 -> 3.8, 3.8->3.9
2. Update all the dependencies to match nep29: https://pypi.org/project/nep29/ -- Many of our minimum dependencies don't have wheels for python 3.7, this makes it virtually impossible for us to build a test system.
3. Maybe keep a token 3.6 build for pypy support -- I would rather keep a pypy build for pypy support.
4. Update the wheel matrix to drop wheels for 3.6.

CC: @terencehonles i know you've been working on adding 3.9 support to our test matrix, and I think dropping 3.6 makes it much easier to think about which configurations you want to add for 3.9.

[hmaarrfk]

I'm also in support of releasing a 0.18 Python 3.6 wheel since it just seems like too much infrastructure change at the last minute.

[stefanv]

I would strongly consider dropping Python 3.6 to be in sync with the rest of the community and with the NumPy NEP.

[terencehonles]

I don't mind trying to iterate on Python 3.9 CI coverage regardless of when Python 3.6 is dropped. As mentioned on the PR, the wheels build on Linux and I just needed to poke at the Windows builds a little.

[jni]

To summarise positions here:

• @hmaarrfk was concerned about dropping 3.6 so close to a release since it would be a major infrastructure change. However, Travis forced our hand with that (we are undergoing the infrastructure change anyway) and I think his comment here suggests he's ok with dropping 3.6 now?
• @stefanv is in favour in order to follow the community (including NumPy itself).
• @emmanuelle is concerned that some platforms such as Google Colab are still on 3.6.

In my opinion the whole point of the NEP-29 standard is to make these decisions easy and avoid this sort of debate altogether, and we should just follow it. So I'd like to release 0.18 without the 3.6 wheels and with python_requires>=3.7.

[hmaarrfk]

I was worried about infrastructure change, but I rather like the 3.6->3.7, 3.7->3.8, 3.8->3.9 build transition.

I didn't want to "drop" 3.6, THEN "add" 3.9. Recent PRs have added 3.9, so we are all good.