We are currently shipping our unit tests (`onnx.test`) in the Python package. These tests, which are different from `onnx.backend.test`, are not relevant for downstream users. Furthermore, they are not usable with the regular dependencies of the `onnx` package (i.e., we actually ship a broken package today if one were to be pedantic about this). With this PR I'd like to move these out of the package (i.e., `onnx/`) into the root-level `tests/` which is more idiomatic in Python these days. I don't see why a downstream package would import anything from `onnx.test`, and I wasn't able to find an open-source project doing so (see https://grep.app/search?regexp=true&q=%28%28from%29%7C%28import%29%29%5Csonnx%5C.test). --------- Signed-off-by: Christian Bourjau <christian.bourjau@quantco.com> Signed-off-by: Christian Bourjau <cbourjau@users.noreply.github.com> Co-authored-by: Copilot Autofix powered by AI <175728472+Copilot@users.noreply.github.com> Co-authored-by: Andreas Fehlner <fehlner@arcor.de>
4.6 KiB
CLAUDE.md — ONNX Project Guide
ONNX (Open Neural Network Exchange) — open-source standard format for AI models. Python + C++ codebase using protobuf for serialization. Builds and runs on Linux, macOS, and Windows — keep all three platforms in mind when making changes.
Also follow the shared AI assistant guidelines in .github/copilot-instructions.md.
Before committing, pushing, filing an issue, or opening a pull request, review CONTRIBUTING.md — it defines the PR process, branch/CI expectations, and coding style. When writing up a bug report or evaluating its severity, check SECURITY.md's disclosure policy first: easily-discovered bugs (found with widely available tooling) are fine as a normal public issue or PR, but a non-trivial security vulnerability must be reported privately via GitHub Security Advisories, not a public issue.
Project Norms
- Follow the ONNX Code of Conduct. All generated code, comments, commit messages, and PR descriptions must be professional, welcoming, and free of hostile, discriminatory, or demeaning language.
- ONNX is an open standard — changes to operator definitions, proto schemas, or the IR spec affect the entire ML ecosystem. Be conservative and deliberate with spec-level changes.
- Stay vendor-neutral. Do not favor any specific framework, runtime, or hardware in code or comments.
- Preserve backward compatibility. Breaking changes to the spec or public API have outsized impact across the ecosystem.
- Match existing code patterns and conventions — read surrounding code before making changes.
- Keep PRs focused. Do not bundle unrelated changes or refactor code outside the scope of the task.
- New operators must follow the process in
docs/AddNewOp.md. - Do not introduce new dependencies as a matter of course. If one genuinely seems necessary, it must be MIT- or Apache-2.0-licensed, and should be raised with maintainers rather than added unilaterally.
Build
pip install -e . -v # Development install
ONNX_BUILD_TESTS=1 pip install -e . -v # With C++ tests
If pixi is available in your environment, pixi run install (and pixi run pytest, pixi run gtest, pixi run gen-all) is the preferred, more reproducible way to build and test — see pixi.toml for the full task list. Fall back to the plain commands below when pixi isn't available.
Pure Python changes take effect immediately in editable installs. C++ changes require rebuild.
Testing
pytest # All Python tests
# C++ tests (build with ONNX_BUILD_TESTS=1 first)
# Linux/macOS:
LD_LIBRARY_PATH=./.setuptools-cmake-build/ .setuptools-cmake-build/onnx_gtests
# Windows:
.setuptools-cmake-build\Release\onnx_gtests.exe
Tests live in tests/ with *_test.py naming.
Linting
lintrunner init # First-time setup
lintrunner # Lint changed files
lintrunner -a # Auto-fix
Runs ruff, mypy, clang-format, editorconfig-checker, and a namespace checker. lintrunner must pass with no errors before a coding task is considered complete.
Code Conventions
- All Python files require
from __future__ import annotations - No relative imports — use absolute imports from
onnx - Copyright header on all files:
# Copyright (c) ONNX Project Contributors+# SPDX-License-Identifier: Apache-2.0 - DCO sign-off required on all commits (
git commit -s)
Auto-Generated Files (Do Not Edit)
Edit the source, then regenerate. CI verifies these are up to date.
| Generated files | Source of truth | Regenerate with |
|---|---|---|
docs/Operators.md, docs/Changelog.md, docs/TestCoverage.md |
Op schemas in onnx/defs/ |
python onnx/defs/gen_doc.py |
onnx/*_pb2.py, onnx/*_pb.h, onnx/onnx_data.proto |
onnx/onnx.in.proto, onnx/onnx-ml.in.proto |
python onnx/gen_proto.py |
Edit .in.proto files, not .proto files. When adding/changing operator schemas, run all three scripts.
C++/Python Boundary
Core validation (checker), shape inference, and version conversion are C++ exposed via nanobind (onnx_cpp2py_export/). Operator schemas are defined in C++ under onnx/defs/. Helper utilities, reference implementation, parser, and compose are pure Python.
ONNX_ML flag (on by default): controls traditional ML types (sequences, maps, sparse tensors). When enabled, builds use onnx-ml.in.proto instead of onnx.in.proto.
Build artifacts go to .setuptools-cmake-build/.