Home / FAQ
Questions teams ask before they swap
Everything here reflects how rpytest already works — a Rust CLI over a warm daemon hosting real pytest. See how it works and the comparisons for detail.
+ Is rpytest really a drop-in replacement for pytest?
Yes, in a measurable sense. CLI flags match pytest (-k, -m, --lf, -x, --maxfail, --collect-only, node-ID selectors), config is read in place from pytest.ini / pyproject.toml / tox.ini / setup.cfg, and exit codes and JUnit XML match exactly. Console stdout is similar but not byte-identical. Run rpytest --verify-dropin to diff collected node IDs, outcomes, and exit codes against pytest on your own suite.
+ Does rpytest re-implement pytest?
No. rpytest is a small Rust CLI plus a Python daemon. The daemon hosts a real pytest process, so your fixtures, conftest.py, parametrization, plugins, and hooks all run in genuine pytest. The Rust side handles flag parsing, selection, parallel dispatch, and result streaming.
+ Do my plugins and fixtures still work?
In general, yes — the daemon hosts pytest, so plugins load and fixtures run as they always have. The most likely friction is a plugin that assumes a fresh Python process per invocation or monkey-patches import machinery and holds module-level state across runs. --verify-dropin flags exactly which tests disagree and whether at collection or execution time.
+ How is it faster?
Two sources. First, the daemon keeps Python warm, so you skip interpreter startup, plugin import, and test collection on every invocation — that fixed cost is paid once per session. Second, the Rust CLI does filtering, parallel dispatch, and aggregation without paying Python overhead. The BENCHMARK.md figures come from one machine and a synthetic 500-test suite and are not extrapolated; measure your own suite.
+ Are exit codes and test reports the same?
Exit codes and JUnit XML match pytest exactly, by design, so CI gates and report parsers keep working. Console output is similar but not byte-identical — if your tooling parses pytest stdout character-for-character, run the drop-in verifier on a representative suite first.
+ Does rpytest replace pytest-xdist?
For parallel execution, yes — rpytest -n and -n auto are built in with duration-aware scheduling and no plugin install. It also skips xdist's per-worker startup cost. Keep xdist if you specifically depend on its distribution semantics like dist=loadfile or loadgroup.
+ How does the daemon stay in sync when I change code?
Watch mode re-runs affected tests on change, and the daemon re-collects when the suite changes. For a guaranteed clean re-import in a long session, stop it with rpytest --daemon-stop and the next run starts a fresh daemon.
+ How do I manage or restart the daemon?
The daemon is a local, long-lived process with no remote control plane. Inspect it with rpytest --daemon-status, stop it with rpytest --daemon-stop, and tidy its state with rpytest --cleanup.
+ Can I run rpytest in CI?
Yes. Built-in parallelism (-n auto), deterministic sharding (--shard / --total-shards), and flakiness controls (--reruns, --flaky-report) remove the xdist install step and cut fixed cost on reruns. Where a runner can keep the daemon alive across steps, collection is paid once. Some runners cannot keep a long-lived process alive between invocations — there the daemon starts fresh per step, so measure the gain with --verify-dropin.
+ How do I install it?
pip install rpytest pulls in both the Rust CLI and the daemon binary. Homebrew (brew install neul-labs/tap/rpytest), npm (npm install -g rpytest), and cargo (cargo install rpytest rpytest-daemon) are also available for non-pip environments. rpytest is MIT-licensed with source at github.com/neul-labs/rpytest.