Add pyre-check 0.10.0 - #2661
Merged
Merged
Conversation
Build pyre.bin (OCaml 4.14.2 + flambda via opam, as upstream's pysa workflow does) in a riscv64/ubuntu:24.04 container, package it with upstream's scripts/pypi, and run upstream's deliberately_vulnerable_flask_app Pysa integration test against the installed wheel.
luhenry
added a commit
that referenced
this pull request
Oct 3, 2026
Contributor
|
build_pypi_package.py builds the wheel under tempfile.mkdtemp(), which defaults to /tmp, then os.replace()s it into --output-dir (../dist, resolving to /workspace/dist). Inside the riscv64/ubuntu:24.04 container, /tmp is the container's own overlay/tmpfs, a different device from /workspace (bind-mounted from the runner host via `podman run -v`), so os.replace() (rename(2)) fails with "OSError: [Errno 18] Invalid cross-device link". Point TMPDIR at /workspace/tmp, on the same bind-mounted filesystem as ../dist, so the wheel's final move stays on one device. Set inside riscv64-build.sh so it applies to the container's own python process, not just the GitHub Actions runner host.
luhenry
added a commit
that referenced
this pull request
Oct 3, 2026
PR #2661's first CI run failed moving the built wheel into dist/ with "Invalid cross-device link": pyre-check's build_pypi_package.py builds in /tmp (tempfile.mkdtemp) and os.replace()s into ../dist, but inside the riscv64/ubuntu:24.04 podman container /tmp and the bind-mounted /workspace are different devices. Fixed on the pyre-check branch by pointing TMPDIR at /workspace/tmp inside the container.
…mparison The integration test died with `pyrefly.pysa.json: No such file or directory`. Pyrefly walked the whole checkout (auto-config rooted at /workspace/pyproject.toml), hit source/pyrefly.exe, a symlink setup.py made in the build container to /tmp/buildenv/bin/pyrefly that dangles in the test container, and aborted with exit 1. The Pysa client reads exit 1 as "type errors found" and ran pyre.bin on a report that was never written. Not riscv64-specific and not caused by the TMPDIR change. Fixing the walk would not make the test pass: v0.10.0 removed the Pyre1 backend (--use-pyre1 raises), so the runner always compares against result.pyrefly.json, which upstream never added (only Pyre1 result.json). Upstream's own pysa workflow badge is failing on main. Scope Pyrefly to the app with an empty pyrefly.toml, run the same `pyre analyze --use-pyrefly --no-verify` the runner runs, and require taint issues in app.py, printing the overlap with the Pyre1 expectations.
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.
pyre-check0.10.0The wheel ships
pyre.bin, an OCaml binary (OCaml 4.14.2 with flambda, built through opam). Upstream publishes no riscv64 wheel, only a manylinux1_x86_64 one.Mirrors upstream's
pysa.ymland itsscripts/pypipackaging.Differs from upstream
riscv64/ubuntu:24.04container - the riscv64 equivalent of upstream'subuntu-latestwith apt opam--releaseprofile - this is what the PyPI binary uses, not the dev build CI testssetuptools<70andwheel==0.38.4- the generator named in the released wheelsTesting
deliberately_vulnerable_flask_appPysa integration test, run against the installed wheelLicense: Same as upstream:
pyre.binstatically links the OCaml runtime and the opam libraries.Patches
0001-scripts-pypi-package-the-client-as-Pysa.patch- Backport [facebook/Pysa@f3057a5]. Without it the client ships aspyre_check, but the released 0.10.0 wheels ship it asPysa.0002-Build-and-package-pyre.bin-on-riscv64.patch- To upstream. On rv64gc,pausedoes not assemble, the fixed 80 TiB shm address is out of range under Sv39, and the packaging script rejects the riscv64 ld.so. riscv64-only.