~~Build abi3 wheel for python 3.13, 3.14...~~ and build modernizing

[Bing-su]

Improves the project's build and test processes by adopting uv for dependency management and build abi3 wheel for future compatibility

• Migrates from pip and pipx to uv for faster and more efficient dependency resolution and package building.
• Introduces support for testing against multiple Python versions in the unit test workflow.
• Constrains numpy version and updates setuptools version.

---

As shown in the polars deployment above, deploying in the limited api format ensures that future versions of Python can continue to use the release.

---

        numpy:
          - oldest-supported-numpy
          - numpy>=2.0.0

I excluded numpy==1.26 because it takes a long time to build on newer versions of python and fails on freethreading python.

---

Limited API wheel for python 3.12

The numpy limited api build requires python 3.11. (numpy/numpy#26756 (comment))

If you are prepared to restrict yourself to Python versions 3.12+, then Cython will use the “vectorcall” interface in Limited API mode. This doesn’t enable any new functionality, but it does give a noticeable performance improvement. (Outside of the Limited API, Cython almost always uses this interface).

However, as the Cython documentation says, there are performance benefits when setting it to 3.12 or higher, I set the ABI to 3.12.

[maxclaey]

Upvote for this PR, specifically for releasing python 3.13 wheels. Currently the from-source build can link to another numpy ABI than is available at runtime, causing runtime failures like

File "pycocotools/_mask.pyx", line 150, in pycocotools._mask.decode
 File "pycocotools/_mask.pyx", line 98, in pycocotools._mask.Masks.__array__
 File "/usr/local/lib/python3.13/site-packages/numpy/__init__.py", line 414, in __getattr__
 raise AttributeError("module {!r} has no attribute "
 "{!r}".format(__name__, attr))
AttributeError: module 'numpy' has no attribute 'NPY_OWNDATA'

[torsteingrindvik]

Thanks, I had the NPY_OWNDATA issue but installed this PR via

pip install 'git+https://github.com/ppwwyyxx/cocoapi.git@refs/pull/27/head#subdirectory=PythonAPI' 

which made the numpy issue go away for me.

[isaaccorley]

Upvote on this as well. This would fix torchgeo's CI which is breaking due to this.

cc @adamjstewart

[adamjstewart]

NPY_OWNDATA issue will be fixed by #28

[ppwwyyxx]

Thanks, two questions:

• Although abi3 wheels are enabled for 3.12+, I think the cibuildwheel action will still build wheels for 3.13, etc, is that right?
  If that is right, what is the point of enabling abi3 wheels? Is it for supporting unreleased python versions ?

• There are many independent changes here - can you split the abi3 changes into a separate PR? Since that is a bigger change and may require a separate release from the rest

[Bing-su]

Building cp313-manylinux_x86_64 wheel
CPython 3.13 manylinux x86_64

Setting up build environment...
  
      + /opt/python/cp39-cp39/bin/python -c 'import sys, json, os; json.dump(os.environ.copy(), sys.stdout)'
      + which python
      + which uv
                                                              ✓ 0.08s

Found previously built wheel pycocotools-2.0.9-cp312-abi3-manylinux_2_17_x86_64.manylinux2014_x86_64.whl, that's compatible with cp313-manylinux_x86_64. Skipping build step...

1. No. cibuildwheel stops building when it finds a compatible file, and only tests it. Like the polars above, abi3 wheel is guaranteed to be compatible with future versions of Python, which is great for a project like this that has very few releases.

2. Sure. I'll just leave the build modernization part here.

[ppwwyyxx]

will this change cause more compiler warnings during build?

[Bing-su]

  running bdist_wheel
  running build
  running build_py
  creating build/lib.linux-x86_64-cpython-39/pycocotools
  copying pycocotools/mask.py -> build/lib.linux-x86_64-cpython-39/pycocotools
  copying pycocotools/__init__.py -> build/lib.linux-x86_64-cpython-39/pycocotools
  copying pycocotools/coco.py -> build/lib.linux-x86_64-cpython-39/pycocotools
  copying pycocotools/cocoeval.py -> build/lib.linux-x86_64-cpython-39/pycocotools
  running build_ext
  building 'pycocotools._mask' extension
  creating build/temp.linux-x86_64-cpython-39/common
  creating build/temp.linux-x86_64-cpython-39/pycocotools
  gcc -pthread -Wno-unused-result -Wsign-compare -DNDEBUG -g -fwrapv -O3 -Wall -fPIC -I/tmp/build-env-w208wvqr/lib/python3.9/site-packages/numpy/_core/include -I./common -I/tmp/build-env-w208wvqr/include -I/opt/_internal/cpython-3.9.22/include/python3.9 -c ./common/maskApi.c -o build/temp.linux-x86_64-cpython-39/common/maskApi.o
  gcc -pthread -Wno-unused-result -Wsign-compare -DNDEBUG -g -fwrapv -O3 -Wall -fPIC -I/tmp/build-env-w208wvqr/lib/python3.9/site-packages/numpy/_core/include -I./common -I/tmp/build-env-w208wvqr/include -I/opt/_internal/cpython-3.9.22/include/python3.9 -c pycocotools/_mask.c -o build/temp.linux-x86_64-cpython-39/pycocotools/_mask.o
  In file included from /tmp/build-env-w208wvqr/lib/python3.9/site-packages/numpy/_core/include/numpy/ndarraytypes.h:1909,
                   from /tmp/build-env-w208wvqr/lib/python3.9/site-packages/numpy/_core/include/numpy/ndarrayobject.h:12,
                   from /tmp/build-env-w208wvqr/lib/python3.9/site-packages/numpy/_core/include/numpy/arrayobject.h:5,
                   from pycocotools/_mask.c:1141:
  /tmp/build-env-w208wvqr/lib/python3.9/site-packages/numpy/_core/include/numpy/npy_1_7_deprecated_api.h:17:2: warning: #warning "Using deprecated NumPy API, disable it with " "#define NPY_NO_DEPRECATED_API NPY_1_7_API_VERSION" [-Wcpp]
     17 | #warning "Using deprecated NumPy API, disable it with " \
        |  ^~~~~~~
  gcc -pthread -shared build/temp.linux-x86_64-cpython-39/common/maskApi.o build/temp.linux-x86_64-cpython-39/pycocotools/_mask.o -o build/lib.linux-x86_64-cpython-39/pycocotools/_mask.cpython-39-x86_64-linux-gnu.so
  installing to build/bdist.linux-x86_64/wheel
  running install
  running install_lib
  creating build/bdist.linux-x86_64/wheel
  creating build/bdist.linux-x86_64/wheel/pycocotools
  copying build/lib.linux-x86_64-cpython-39/pycocotools/mask.py -> build/bdist.linux-x86_64/wheel/./pycocotools
  copying build/lib.linux-x86_64-cpython-39/pycocotools/__init__.py -> build/bdist.linux-x86_64/wheel/./pycocotools
  copying build/lib.linux-x86_64-cpython-39/pycocotools/coco.py -> build/bdist.linux-x86_64/wheel/./pycocotools
  copying build/lib.linux-x86_64-cpython-39/pycocotools/cocoeval.py -> build/bdist.linux-x86_64/wheel/./pycocotools
  copying build/lib.linux-x86_64-cpython-39/pycocotools/_mask.cpython-39-x86_64-linux-gnu.so -> build/bdist.linux-x86_64/wheel/./pycocotools
  running install_egg_info
  running egg_info
  writing pycocotools.egg-info/PKG-INFO
  writing dependency_links to pycocotools.egg-info/dependency_links.txt
  writing requirements to pycocotools.egg-info/requires.txt
  writing top-level names to pycocotools.egg-info/top_level.txt
  dependency /tmp/build-env-w208wvqr/lib/python3.9/site-packages/numpy/_core/include/numpy/arrayobject.h won't be automatically included in the manifest: the path must be relative
  dependency /tmp/build-env-w208wvqr/lib/python3.9/site-packages/numpy/_core/include/numpy/arrayscalars.h won't be automatically included in the manifest: the path must be relative
  dependency /tmp/build-env-w208wvqr/lib/python3.9/site-packages/numpy/_core/include/numpy/ndarrayobject.h won't be automatically included in the manifest: the path must be relative
  dependency /tmp/build-env-w208wvqr/lib/python3.9/site-packages/numpy/_core/include/numpy/ndarraytypes.h won't be automatically included in the manifest: the path must be relative
  dependency /tmp/build-env-w208wvqr/lib/python3.9/site-packages/numpy/_core/include/numpy/ufuncobject.h won't be automatically included in the manifest: the path must be relative
  dependency common/maskApi.h won't be automatically included in the manifest: the path must be inside the project root
  reading manifest file 'pycocotools.egg-info/SOURCES.txt'
  reading manifest template 'MANIFEST.in'
  writing manifest file 'pycocotools.egg-info/SOURCES.txt'
  Copying pycocotools.egg-info to build/bdist.linux-x86_64/wheel/./pycocotools-2.0.9-py3.9.egg-info
  running install_scripts
  creating build/bdist.linux-x86_64/wheel/pycocotools-2.0.9.dist-info/WHEEL
  creating '/tmp/cibuildwheel/built_wheel/.tmp-r8ogyqtm/pycocotools-2.0.9-cp39-cp39-linux_x86_64.whl' and adding 'build/bdist.linux-x86_64/wheel' to it
  adding 'pycocotools/__init__.py'
  adding 'pycocotools/_mask.cpython-39-x86_64-linux-gnu.so'
  adding 'pycocotools/coco.py'
  adding 'pycocotools/cocoeval.py'
  adding 'pycocotools/mask.py'
  adding 'pycocotools-2.0.9.dist-info/METADATA'
  adding 'pycocotools-2.0.9.dist-info/WHEEL'
  adding 'pycocotools-2.0.9.dist-info/top_level.txt'
  adding 'pycocotools-2.0.9.dist-info/RECORD'
  removing build/bdist.linux-x86_64/wheel
  Successfully built pycocotools-2.0.9-cp39-cp39-linux_x86_64.whl
      + /opt/python/cp39-cp39/bin/python -c 'import sys, json, glob; json.dump(glob.glob('"'"'/tmp/cibuildwheel/built_wheel/*.whl'"'"'), sys.stdout)'
      + rm -rf /tmp/cibuildwheel/repaired_wheel
      + mkdir -p /tmp/cibuildwheel/repaired_wheel

No. It seems like there is no difference.

https://github.com/Bing-su/cocoapi/actions/runs/15343077401/job/43173296253