Skip to content

Conversation

XueSongTap
Copy link

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

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 XueSongTap requested review from a team as code owners August 31, 2025 01:03
@XueSongTap
Copy link
Author

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
Copy link
Member

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

@take-cheeze
Copy link
Member

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/

Signed-off-by: yexiaochuan <tap91624@gmail.com>
@XueSongTap
Copy link
Author

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

latest commit sign off added

@XueSongTap
Copy link
Author

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
Copy link
Author

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
Copy link
Member

andife commented Aug 31, 2025

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

@justinchuby
Copy link
Member

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

@take-cheeze
Copy link
Member

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.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
4 participants