From cfc094a875c9da8d86c1a9560f2ca0d6ed899e2a Mon Sep 17 00:00:00 2001 From: Joshua Elliott Date: Wed, 12 Aug 2026 09:17:51 -0600 Subject: [PATCH] Don't build a Rust test harness for the bindings crate crates/oxen-py has no Rust tests, and is not the right place for them: it is a thin PyO3 binding layer, so a Rust test would exercise PyO3's interface more than our own logic. That logic lives in liboxen and is tested through the Python suite, which exercises the bindings against the module maturin builds. Building the harness anyway is not free. A test target is an executable, so it embeds libpython rather than resolving symbols at load time the way the cdylib does, and PyO3 emits the matching rpath only when the interpreter is a framework build. Against a plain shared interpreter the harness aborts at launch, before libtest starts, so `cargo test --workspace` fails with no test failure to point at. --- crates/oxen-py/Cargo.toml | 3 +++ 1 file changed, 3 insertions(+) diff --git a/crates/oxen-py/Cargo.toml b/crates/oxen-py/Cargo.toml index 8c1b6f882..33a96e523 100644 --- a/crates/oxen-py/Cargo.toml +++ b/crates/oxen-py/Cargo.toml @@ -12,6 +12,9 @@ publish = false [lib] name = "oxen_py" # The native extension module. Users still `import oxen` via the Python package wrapper. crate-type = ["cdylib"] # PyO3 needs this crate to be a cdylib so it can link against it. +# We don't add Rust tests here. This is a thin binding layer, so a Rust test would be testing PyO3's +# interface more than our own logic. We test our logic through the Python suite. +test = false [features] default = []