build: add pyproject.toml for PEP 517/518 support

[XueSongTap]

fix #209

This PR introduces a minimal pyproject.toml so that the package can be built through the PEP 517 interface.
Currently it still delegates to setup.py (setuptools.build_meta backend), so all custom CMake build logic remains unchanged.

Version constraints

• cmake>=3.22 – aligned with cmake_minimum_required(VERSION 3.22) in the project’s CMakeLists.txt.
• protobuf>=4.25.1 – consistent with [onnx/onnx requirements](https://github.com/onnx/onnx/blob/main/requirements.txt).
• setuptools>=68, wheel – ensure stable PEP 517/518/660 support and wheel building.

Next steps

This is only the first step: future work can gradually migrate static metadata (name, license, classifiers, URLs, entry points, etc.) from setup.py into the [project] section of pyproject.toml.

[XueSongTap]

selt test:

(.optimizer) yxc@yxc-MS-7B89:~/code/2508/optimizer$ pip install -e .
Obtaining file:///home/yxc/code/2508/optimizer
  Installing build dependencies ... done
  Checking if build backend supports build_editable ... done
  Getting requirements to build editable ... done
  Installing backend dependencies ... done
  Preparing editable metadata (pyproject.toml) ... done
Requirement already satisfied: onnx in ./.optimizer/lib/python3.12/site-packages (from onnxoptimizer==0.3.19) (1.19.0)
Requirement already satisfied: numpy>=1.22 in ./.optimizer/lib/python3.12/site-packages (from onnx->onnxoptimizer==0.3.19) (2.3.2)
Requirement already satisfied: protobuf>=4.25.1 in ./.optimizer/lib/python3.12/site-packages (from onnx->onnxoptimizer==0.3.19) (6.32.0)
Requirement already satisfied: typing_extensions>=4.7.1 in ./.optimizer/lib/python3.12/site-packages (from onnx->onnxoptimizer==0.3.19) (4.15.0)
Requirement already satisfied: ml_dtypes in ./.optimizer/lib/python3.12/site-packages (from onnx->onnxoptimizer==0.3.19) (0.5.3)
Building wheels for collected packages: onnxoptimizer
  Building editable for onnxoptimizer (pyproject.toml) ... done
  Created wheel for onnxoptimizer: filename=onnxoptimizer-0.3.19-0.editable-cp312-cp312-linux_x86_64.whl size=8530 sha256=85d3b0e1602848b3ececb2c23b1833b463ab7dc2731dd914188f63e39f62d8ee
  Stored in directory: /tmp/pip-ephem-wheel-cache-0ltemfja/wheels/e8/8e/f5/56d4685f848ba42247ed22c762fdcd882cd39d564d2d49530a
Successfully built onnxoptimizer
Installing collected packages: onnxoptimizer
  Attempting uninstall: onnxoptimizer
    Found existing installation: onnxoptimizer 0.3.19
    Uninstalling onnxoptimizer-0.3.19:
      Successfully uninstalled onnxoptimizer-0.3.19
Successfully installed onnxoptimizer-0.3.19

[notice] A new release of pip is available: 24.0 -> 25.2
[notice] To update, run: pip install --upgrade pip

[take-cheeze]

Please update you commits with --signoff enabled since it's required

[take-cheeze]

Thank you for supporting the project.
Before reviewing deeply is migrating https://github.com/onnx/optimizer/blob/main/setup.cfg to pyproject.toml hard?
I know flake8 isn't easy to migrate but there is project like: https://pypi.org/project/Flake8-pyproject/

[XueSongTap]

Please update you commits with --signoff enabled since it's required

latest commit sign off added

[XueSongTap]

Thank you for supporting the project. Before reviewing deeply is migrating https://github.com/onnx/optimizer/blob/main/setup.cfg to pyproject.toml hard? I know flake8 isn't easy to migrate but there is project like: https://pypi.org/project/Flake8-pyproject/

I think deeply migrating to pyproject.toml not hard. I'll have a try

[XueSongTap]

Thank you for supporting the project. Before reviewing deeply is migrating https://github.com/onnx/optimizer/blob/main/setup.cfg to pyproject.toml hard? I know flake8 isn't easy to migrate but there is project like: https://pypi.org/project/Flake8-pyproject/

I took a closer look. Migrating just the metadata and tool configs into pyproject.toml may be easy, but a full migration is tougher than it looks.

Our current setup.py has a lot of custom build logic — things like cmake_build, create_version, build_py, build_ext — and those hook into environment variables and CMake flags.

To remove setup.py entirely we’d need to rework that logic inside CMake or switch to something like scikit-build-core, which means touching both the build system and the packaging. It will definitely more effort than a simple config move.

[andife]

I think there is no need to remove setup.py completely at the moment..

[justinchuby]

That’s right. setup.py should still be supported. It’s only that using setup.py develop etc. directly is deprecated.

[take-cheeze]

setup.py is basically a wrapper for cmake so we could migrate it to https://packaging.python.org/en/latest/key_projects/#scikit-build-core in the future
I'd like to know setup.cfg is migratable since I don't want to maintain it with pyproject.toml.

[sonarqubecloud]

Quality Gate passed

Issues
0 New issues
0 Accepted issues

Measures
0 Security Hotspots
0.0% Coverage on New Code
0.0% Duplication on New Code

See analysis details on SonarQube Cloud