[Bot] Update dependencies

[cibuildwheel-bot]

Update the versions of our dependencies.

PR generated by "Update dependencies" workflow.

[henryiii]

Pyodide change?

pyodide xbuildenv search --json --all
                                                             ✕ 16.99s
----------------------------- Captured stderr call -----------------------------
Usage: pyodide xbuildenv [OPTIONS] COMMAND [ARGS]...
Try 'pyodide xbuildenv --help' for help.
╭─ Error ──────────────────────────────────────────────────────────────────────╮
│ No such command 'search'.                                                    │
╰──────────────────────────────────────────────────────────────────────────────╯
Error: cibuildwheel: Command ['/tmp/cibw-run-g2hqjk7m/cp312-pyodide_wasm32/build/venv/bin/pyodide', 'xbuildenv', 'search', '--json', '--all'] failed with code 2. 

[joerick]

So the package resolver, when the constraints are missing, resolves to pyodide-build==0.25.0 for some reason. But I can't figure the reason it's going so far back, rather than just using the latest?

[joerick]

Ah, this is the issue. Pyodide-build pins the version of auditwheel-enscripten, but we specify it here in the --upgrade command. I don't actually see why we'd depend on auditwheel-enscripten at all, so I'll try removing it.

[joerick]

Also, TIL that the ordering of packages in pip install --upgrade decides the priorities that the resolver uses. By listing auditwheel-emscripten first, the resolver was prioritising that upgrade over others - hence the backtracking on pyodide-build, which was listed last.

[joerick]

Looks like it's working. I'll pull it out to its own PR because it's really a bug fix.

[joerick]

See #2548 for the fix.

[henryiii]

The more tightly dependencies are constrained, the more problems occur, always. :)

[xavier2k6]

BTW pyodide-lock==0.1.0a7 -> latest is pyodide-lock==0.1.0a9

https://github.com/pyodide/pyodide-lock/blob/0.1.0a9/CHANGELOG.md
https://github.com/pyodide/pyodide-lock/releases/tag/v0.1.0a9
https://github.com/pyodide/pyodide-lock/releases/tag/v0.1.0a8

[henryiii]

That's coming out of the resolve, so it's likely more strict limit issues from pyodide. Yes, looks like the last release of pyodide-build strictly pins it to a7: https://inspector.pypi.io/project/pyodide-build/0.30.5/packages/76/a1/79ea06a74a6d0819352a39e21751a179cf16e65cce2f79f7f017e0c9cc1c/pyodide_build-0.30.5.tar.gz/pyodide_build-0.30.5/pyproject.toml

[henryiii]

Those are really tightly constrained, I'd highly recommend loosening them up. For example, allowing patch releases of pyodide-lock and auditwheel-enscripten would allow shipping fixes for those projects without having to update and re-release pyodide-build every time.

[ryanking13]

Thanks. Let me try relaxing the constraints. I think our lockfile schema is quite stable now.