Use oldest-supported-numpy in pyproject.toml and explicitly require Python 3.6

[astrofrog]

Currently the pyproject.toml file is missing a Numpy version for Python 3.8. Rather than add this, I've switched this file to use the oldest-supported-numpy meta-package which is equivalent to specifying all the environment markers (see the README for that project) but means that the pyproject.toml file here doesn't need to be updated in future when a new version of Python is released since this just requires a new release of oldest-supported-numpy.

It looks like bottleneck requires Python 3.6 based on the classifiers, so I've also added an explicit python_requires which will prevent older Python versions from downloading newer releases.

[codecov-io]

Codecov Report

Merging #306 into master will not change coverage.
The diff coverage is n/a.

@@           Coverage Diff           @@
##           master     #306   +/-   ##
=======================================
  Coverage   85.11%   85.11%           
=======================================
  Files          29       29           
  Lines        3911     3911           
  Branches      290      290           
=======================================
  Hits         3329     3329           
  Misses        539      539           
  Partials       43       43           

---

Continue to review full report at Codecov.

Legend - Click here to learn more
Δ = absolute <relative> (impact), ø = not affected, ? = missing data
Powered by Codecov. Last update 8d980f4...7daabb6. Read the comment docs.

[qwhelan]

Thanks for submitting this - I unfortunately won't have bandwidth to dig in until the weekend as I'm on call this week. One thing I'd like to make sure is that the test suite can reproduce the issue before merging this PR.

[qwhelan]

Unfortunately I'm unable to reproduce the Arch error with the current approach in #307 so it's unclear if this resolves #277.

I'm inclined to merge as I'd like to not have to manually sync the pyproject.toml file with scipy/pandas - if you can give any additional insight into how to test that #277 is fixed with this approach, I'd appreciate it.

[qwhelan]

@astrofrog Are there any other projects using this or planning to start doing so?

Let's say I release bottleneck 1.4.0 with py36 and numpy 1.16 being in the supported window. Two years from now, they've fallen out of support. Can I build bottleneck 1.4.0 with py36 and numpy 1.16 if this is a dependency?

[astrofrog]

@qwhelan - yes this is used by e.g. astropy for example:

https://github.com/astropy/astropy/blob/master/pyproject.toml#L7

There are a number of other packages using this too:

https://github.com/search?l=TOML&q=oldest-supported-numpy&type=Code

Just to be clear, this package doesn't imply that this will be the oldest supported numpy right now, but the oldest version of numpy that works for each Python version. See also the note here:

https://github.com/scipy/oldest-supported-numpy/blob/master/setup.cfg#L17

As you can see, for some of the older Python versions, Numpy 1.13 is used (even though it's not supported right now). In other words, the version of Numpy corresponding to each Python version in the meta-package will never change. The only thing that will change is that new Python versions will be added, along with their corresponding first supported numpy version. Does this make sense?

[astrofrog]

See also the FAQ here: https://github.com/scipy/oldest-supported-numpy (the project is now supported by scipy)

[qwhelan]

Thanks @astrofrog and apologies for the delay!

[astrojuanlu]

Looks like this PR was never released, opened #388 about it.