Wheel files that support numpy 2.0

[Bing-su]

numpy is approaching its 2.0 release.
https://numpy.org/devdocs/dev/depending_on_numpy.html#numpy-2-0-specific-advice

According to numpy's documentation, packages built with numpy 2.0 will work with numpy 1.x, so modifying the build requirements to numpy 2.0 should be fine.

In addition, I've updated to support more platforms.

[ppwwyyxx]

According to #6 , code built with newer numpy does not work with older ones, even in the 1.x era. So I'm not sure whether we could upgrade like this.

At least we should figure out for code built with numpy2.0, what is the oldest numpy that can work with it. Then decide how to upgrade.

[ppwwyyxx]

So to proceed I think we'll need a CI test to build with 2.0, then install an older numpy and call the pycocotools C API to verify the build works. And we want this "older" numpy to be as old as possible because it will become the required minimum for future releases that builds with numpy2.0.

[Bing-su]

According to #6 , code built with newer numpy does not work with older ones, even in the 1.x era. So I'm not sure whether we could upgrade like this.

At least we should figure out for code built with numpy2.0, what is the oldest numpy that can work with it. Then decide how to upgrade.

Since with numpy 1.25.0, numpy works with older version. You can read about it in the deprecated oldest-supported-numpy repository and in the numpy documentation.

1. When you build wheels for your package using a NumPy 1.xx version at build time, those will not work with NumPy 2.0.
2. When you build wheels for your package using a NumPy 2.x version at build time, those will work with NumPy 1.xx.

[Bing-su]

I think I can modify the unittest.yml file to run the tests on different versions of numpy.
Would it be okay to remove the install_from: [source, source_with_pre, sdist] is it okay to remove it? It doesn't seem to have any meaning at this point, and it makes the workflow too long.

[ppwwyyxx]

Thanks. I think source_with_pre can be removed. source and sdist installation are quite different IIRC, so it would be good to keep them.

[Bing-su]

I modified the unittest.yml and you can see that oldest-supported-numpy, numpy<2, and numpy>=2.0.0rc1 all pass the test.

[ppwwyyxx]

Is this going to break python3.7 & 3.8 users?

3.8 seems to have a good amount of users: https://pypistats.org/packages/pycocotools

[Bing-su]

This is because numpy no longer supports versions lower than 3.9 😿.
https://numpy.org/neps/nep-0029-deprecation_policy.html#support-table

The other dependency, matplotlib, also does not support below 3.9.
https://github.com/matplotlib/matplotlib/blob/d45dfbb245b991e51f60a5083d61d0130b2ecc1b/pyproject.toml#L45

By modifying python_requires in setup.py, we can ensure that pycocotools 2.0.7 is selected for Python 3.8 and below. (pip or other dependency manager select the appropriate version.)

[Bing-su]

2.0 is out today, can you make a release?

[ppwwyyxx]

Just made a release from https://github.com/ppwwyyxx/cocoapi/actions/runs/9540578245 . Let me know if you noticed any problems.