dev: Ensure latest setuptools used in CI

[adigitoleo]

It seems like the Python setup action in CI doesn't respect [build-system] in pyproject.toml ☹️ This ensures that the latest setuptools is being used in CI. I made the matching change to the virtual environment setup script.

Maybe this will resolve the failures to install llmvlite in the MacOS runner.

[adigitoleo]

Well, the MacOS CI failure persists. The error message is confusing, as the logs show that setuptools v82 is being used, which is newer than the suggested v70.1, more investigation required.

  × Building wheel for llvmlite (pyproject.toml) did not run successfully.
140
  │ exit code: 1
141
  ╰─> [59 lines of output]
142
      /private/var/folders/yj/mflq9j197hz47cqbjv17r7k00000gn/T/pip-build-env-9ehaqa4p/overlay/lib/python3.13/site-packages/setuptools/_vendor/wheel/bdist_wheel.py:4: FutureWarning: The 'wheel' package is no longer the canonical location of the 'bdist_wheel' command, and will be removed in a future release. Please update to setuptools v70.1 or later which contains an integrated version of this command.

[adigitoleo]

No luck on newer macos runner either. I don't think we want it to build llvmlite anyway should ideally just download a pre-built one? Might need to pin llmvlite version

[Patol75]

Sorry, I cannot manage to make it work either...

[adigitoleo]

No worries I'll consider either pinning llvmlite (in pyproject.toml, kinda ugly as it then affects other platforms) or play around with adding brew insatll llvm before building the wheel on mac. Aside: my home office keyboard is dying so I will come back after a trip to JB 😆

[Patol75]

https://llvmlite.readthedocs.io/en/latest/admin-guide/install.html#things-to-fix-it
https://github.com/seismic-anisotropy/PyDRex/actions/runs/23421445428/job/68127149258

Good luck!

[adigitoleo]

So it looks like llmvlite don't officially support MacOS intel architecture: https://numba.discourse.group/t/resolved-llvmlite-wheels-on-pypi-for-macos-x86/3146. We switched to using MacOS intel rather than ARM in #225 because the CI was failing on ARM for some other reason (logs expired). I will try switching back to see if the other issue is easier to handle than building llvmlite.

[adigitoleo]

Lessons from these new failures:

• ubuntu-slim is too slim, we need more RAM for the tests
• I need to update branch rules to stop expecting 3.11 tests
• One flaky tolerance value on MacOS ARM
• A new error with reading the VTU file on all platforms, copied below in case logs disappear again. Meshio doesn't have new releases since our last good run, so maybe it's coming from updates in base64.py in Python 3.13?

_____________________________ test_steady_specfile _____________________________
tests/test_config.py:13: in test_steady_specfile
    config = _io.parse_config(_io.data("specs") / "steady_mesh.toml")
             ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
/Library/Frameworks/Python.framework/Versions/3.13/lib/python3.13/site-packages/pydrex/io.py:464: in parse_config
    _input = _parse_config_input_steadymesh(_input, path)
             ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
/Library/Frameworks/Python.framework/Versions/3.13/lib/python3.13/site-packages/pydrex/io.py:598: in _parse_config_input_steadymesh
    input["mesh"] = meshio.read(resolve_path(input["mesh"], path.parent))
                    ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
/Library/Frameworks/Python.framework/Versions/3.13/lib/python3.13/site-packages/meshio/_helpers.py:71: in read
    return _read_file(Path(filename), file_format)
           ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
/Library/Frameworks/Python.framework/Versions/3.13/lib/python3.13/site-packages/meshio/_helpers.py:103: in _read_file
    return reader_map[file_format](str(path))
           ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
/Library/Frameworks/Python.framework/Versions/3.13/lib/python3.13/site-packages/meshio/vtu/_vtu.py:577: in read
    reader = VtuReader(filename)
             ^^^^^^^^^^^^^^^^^^^
/Library/Frameworks/Python.framework/Versions/3.13/lib/python3.13/site-packages/meshio/vtu/_vtu.py:405: in __init__
    piece_point_data[c.attrib["Name"]] = self.read_data(c)
                                         ^^^^^^^^^^^^^^^^^
/Library/Frameworks/Python.framework/Versions/3.13/lib/python3.13/site-packages/meshio/vtu/_vtu.py:558: in read_data
    data = reader(self.appended_data[offset:], dtype)
           ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
/Library/Frameworks/Python.framework/Versions/3.13/lib/python3.13/site-packages/meshio/vtu/_vtu.py:448: in read_uncompressed_binary
    byte_string = base64.b64decode(data)
                  ^^^^^^^^^^^^^^^^^^^^^^
/Library/Frameworks/Python.framework/Versions/3.13/lib/python3.13/base64.py:88: in b64decode
    return binascii.a2b_base64(s, strict_mode=validate)
           ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
E   binascii.Error: Incorrect padding

[adigitoleo]

Learning more things as I go. Apparently meshio doesn't support reading VTU in raw format, which is how our VTU was created. The error should be coming from meshio I think, so I opened nschloe/meshio#1571. We will have to somehow regenerate the VTU in a format which meshio accepts (maybe there is a toggle in ParaView) or convert the existing one using VTK API or pyvista.

It's a bit curious why we didn't hit some error with the VTU earlier though, if it is an unsupported format for meshio.