Skip to content

Python 3.14 Support and Pre-built Wheels#32

Open
padraic-padraic wants to merge 7 commits intotrmue:mainfrom
padraic-padraic:main-py14-and-wheels
Open

Python 3.14 Support and Pre-built Wheels#32
padraic-padraic wants to merge 7 commits intotrmue:mainfrom
padraic-padraic:main-py14-and-wheels

Conversation

@padraic-padraic
Copy link
Copy Markdown

@padraic-padraic padraic-padraic commented Feb 26, 2026

This PR enables running relay-bp under Python 3.14, by upgrading the dependencies on numpy and PyO3.

It also adds a workflow to create pre-built Python wheels, based on the example workflow that can be generated using maturin generate-ci. The file, .github/workflows/release.yml includes a step (currently commented out) to allow automatic publishing to PyPI via their 'Trusted Publishing' feature. This would enable researchers to use relay-bp without needing a rust toolchain installed.

It makes one small additional change, namely removing the dev dependencies from the published package and keeping them for local testing only. Feel free to revert that change if you prefer keeping it as before.

@trmue
Copy link
Copy Markdown
Owner

trmue commented Mar 5, 2026

Hi! Thank you for your pull request!
Regression was broken and I only now had the time to fix it. My plan was to have a "stable" main before upgrading packages.

Could you merge main into your branch? I am then happy to review. I am generally in favor of supporting Python3.14. :)

Bumps versions of PyO3 and numpy crates, and resolves warning from PyO3

Resolve outstanding deprecation warning
Use dependency-groups for local dev instead
Lightly modified from maturin generate-ci
Missing arguments for musl, limit Python versions for windows
@padraic-padraic
Copy link
Copy Markdown
Author

Thank you for taking the time! I've rebased this branch onto the latest main, so it should include your latest changes.

@padraic-padraic
Copy link
Copy Markdown
Author

Hmm, over on my own fork I see errors related to the integration with sinter, specifically that the task returns the number of errors as a float. This seems to happen on my system (macOS), even checking out your current main branch, even on Python 3.12

The error message returned is

E           RuntimeError: Worker failed: traceback=Traceback (most recent call last):
E             File "/Users/padraic/Documents/relay-upstream/.venv/lib/python3.12/site-packages/sinter/_collection/_collection_worker_state.py", line 246, in run_message_loop
E               did_some_work = self.do_some_work()
E                               ^^^^^^^^^^^^^^^^^^^
E             File "/Users/padraic/Documents/relay-upstream/.venv/lib/python3.12/site-packages/sinter/_collection/_collection_worker_state.py", line 217, in do_some_work
E               some_work_done = self.compiled_sampler.sample(self.current_task_shots_left)
E                                ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
E             File "/Users/padraic/Documents/relay-upstream/.venv/lib/python3.12/site-packages/sinter/_collection/_sampler_ramp_throttled.py", line 51, in sample
E               result = self.sub_sampler.sample(actual_shots)
E                        ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
E             File "/Users/padraic/Documents/relay-upstream/.venv/lib/python3.12/site-packages/sinter/_decoding/_stim_then_decode_sampler.py", line 216, in sample
E               return AnonTaskStats(
E                      ^^^^^^^^^^^^^^
E             File "<string>", line 8, in __init__
E             File "/Users/padraic/Documents/relay-upstream/.venv/lib/python3.12/site-packages/sinter/_data/_anon_task_stats.py", line 37, in __post_init__
E               assert isinstance(self.errors, int)
E           AssertionError

.venv/lib/python3.12/site-packages/sinter/_collection/_collection_manager.py:385: RuntimeError

@padraic-padraic
Copy link
Copy Markdown
Author

padraic-padraic commented Mar 5, 2026

Actually, found the issue; it seems like it actually is related to a change in sinter, where the internal method classify_discards_and_errors now returns numpy types instead of bare Python types. There's an issue raised over in stim (quantumlib/Stim#1000), for the moment you might want to pin numpy<2.3 if you're using relay-bp alongside stim...

@trmue trmue self-requested a review March 6, 2026 11:34
Copy link
Copy Markdown
Owner

@trmue trmue left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Overall ok. Have a look at the cast vs downcast.
Also there seems to be some issue with the static checks?
Maybe you can have a look?

Image

let matrix = matrix.call_method1("astype", ("uint8",))?;

if let Ok(dense) = matrix.downcast::<PyArray2<Bit>>() {
if let Ok(dense) = matrix.cast::<PyArray2<Bit>>() {
Copy link
Copy Markdown
Owner

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Any specific reason why you would want to remove downcast here?

Copy link
Copy Markdown
Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

So this change comes from changes to PyO3, which you can find in the release notes here: https://pyo3.rs/main/migration#from-026-to-027

Copy link
Copy Markdown
Owner

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Thank you for pointing this out!

stim = [
"stim>=1.15",
"beliefmatching",
"numpy<2.3" # Resolves type issue in sinter, see https://github.com/quantumlib/Stim/issues/1000.
Copy link
Copy Markdown
Owner

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Ok, fine!

@trmue
Copy link
Copy Markdown
Owner

trmue commented Mar 16, 2026

I am travelling the next two weeks and have limited time to help. But maybe to move things forward, the windows regression test failed, here is the output:

  Stored in directory: c:\users\runneradmin\appdata\local\pip\cache\wheels\d3\3b\f8\1808654b6b2d6ed604eac6b8a474c633b0d8c41f5b6a618f90
  Building wheel for pymatching (pyproject.toml): started
  Building wheel for pymatching (pyproject.toml): finished with status 'error'
  error: subprocess-exited-with-error
  
  Building wheel for pymatching (pyproject.toml) did not run successfully.
  exit code: 1
  
  [113 lines of output]
  running bdist_wheel
  running build
  running build_py
  creating python_build_stim\lib.win-amd64-cpython-314\pymatching
  copying src\pymatching\matching.py -> python_build_stim\lib.win-amd64-cpython-314\pymatching
  copying src\pymatching\_cli_argv.py -> python_build_stim\lib.win-amd64-cpython-314\pymatching
  copying src\pymatching\_version.py -> python_build_stim\lib.win-amd64-cpython-314\pymatching
  copying src\pymatching\__init__.py -> python_build_stim\lib.win-amd64-cpython-314\pymatching
  running build_ext
  -- Building for: Visual Studio 17 2022
  -- The C compiler identification is unknown
  -- The CXX compiler identification is unknown
  CMake Error at CMakeLists.txt:2 (project):
    No CMAKE_C_COMPILER could be found.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants