Conversation
Rust/pyo3 maturin project; nuts-rs uses faer (pure Rust) for linear algebra, no BLAS/LAPACK anywhere in the tree, and cargo metadata --filter-platform riscv64gc-unknown-linux-gnu resolves the identical 340-crate set as x86_64 (minus cpufeatures). The optional tch (libtorch) dependency is unused by any default feature. Mirrors upstream's own PyO3/maturin-action-based CI. Testing drives the compiled sampler through nutpie's dependency-free compiled_pyfunc API instead of upstream's stan/pymc/flow pytest suites: stanc3 ships no riscv64 binary, and pymc/flow need numba (-> llvmlite, parked) or jax. All of nutpie's own core runtime deps (pyarrow, pandas, arro3-core, obstore) already have riscv64 wheels on our registry.
luhenry
added a commit
that referenced
this pull request
Sep 28, 2026
Contributor
|
The v0.16.11 tag's committed Cargo.lock still lists the "nutpie" crate itself as version 0.16.10 (a stale self-entry left by upstream's release tooling ahead of the Cargo.toml bump), so cargo needs to update that one line on every build. --locked forbids it: `cargo metadata` fails with "cannot update the lock file ... because --locked was passed", which maturin surfaces as "cargo metadata failed. Does your crate compile with `cargo build`?". Upstream's own ci.yml never passes --locked to maturin-action either, so this also brings the build back in line with upstream's own build shape. Verified locally: cloning the v0.16.11 tag and running `cargo metadata --locked` reproduces the exact error, and the diff from a plain `cargo metadata` (no --locked) touches only that one version line, not the wider dependency graph.
…locked A crate's own release tooling can tag before regenerating Cargo.lock, so the lock's self-entry for the crate names the previous version. cargo happily fixes that one line on an unlocked build, but --locked forbids it outright, and this isn't the "floating deps" case of gotcha 10 (no lock in the sdist at all) since here the whole tree stays pinned except that one line. The fix is to drop --locked to match upstream's own build workflow rather than patch or regenerate Cargo.lock (nutpie 0.16.11, PR #2420).
uv pip install only honors UV_* env vars, not PIP_*. The step used PIP_EXTRA_INDEX_URL, which uv silently ignored, so it resolved against public PyPI only and source-built numpy/scipy/pandas/pyarrow instead of using the riscv64 wheels already on the registry, then failed outright on pyarrow's sdist (needs a system Arrow C++ install not present here). Swap to UV_EXTRA_INDEX_URL, add UV_INDEX_STRATEGY=unsafe-best-match so uv's default first-index strategy doesn't stop at PyPI before reaching the registry, and add UV_ONLY_BINARY for the packages observed building from source.
luhenry
marked this pull request as ready for review
September 28, 2026 21:09
luhenry
added a commit
that referenced
this pull request
Sep 28, 2026
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
nutpie0.16.11Compiles PyMC/Stan's Rust (pyo3/maturin) NUTS sampler, built on nuts-rs, which uses faer (pure Rust) for its linear algebra rather than a BLAS/LAPACK backend. Upstream publishes no riscv64 wheel.
Mirrors upstream's
ci.ymlbuild_linuxjob, usingPyO3/maturin-actiondirectly (as upstream does) rather than cibuildwheel.Differs from upstream
--zig- building natively on the riscv64 runner, not cross-compiling.Matrix: cp312/cp313/cp314 - upstream doesn't build cp314t either (pyo3 0.29, no abi3 feature).
Testing
stanpytest suite, but stanc3 ships no riscv64 binary.pymc/flowneed numba (-> llvmlite, parked) or jax, also unavailable here.compiled_pyfuncAPI on each interpreter, exercising the compiled sampler end to end.License: OK
Built on cp312/cp313/cp314; toy-model sample passed on all three.