Python 3.14 Support and Pre-built Wheels

[padraic-padraic]

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]

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. :)

[padraic-padraic]

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

[padraic-padraic]

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]

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]

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?

[trmue]

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

[padraic-padraic]

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

[trmue]

Thank you for pointing this out!

[trmue]

Ok, fine!

[trmue]

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.

[trmue]

Sorry for only now getting back to you! I think the issue is that Windows+python3.14 is currently not supported for some python modules (pymatching?).

Could you try

matrix:
  python-version: ["3.12", "3.13", "3.14"]
  os: [ubuntu-latest, windows-latest, macos-latest]
  exclude:
    - os: windows-latest
      python-version: "3.14"

[padraic-padraic]

No problem at all, I've been busy myself! Yes, it seems that there were some fixes made in the pymatching repo for the windows builds (oscarhiggott/PyMatching@c60642a) but they've not made a new release yet so we still hit the crash for the moment.

I've made that tweak, please do let me know if you have any other comments

[trmue]

Thank you for your patience! Merging. :)