Files
Christian Bourjau 1e58fd5ec2 Move tests from /onnx/test to /tests (#8253)
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>
2026-08-09 17:33:38 -07:00

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/.