python 3.13 in workflows

[dimbleby]

time to find out what is broken at python 3.13

[dimbleby]

could be worse:

• failure to install on macos
  • looks like the problem is cffi
  • per cffi fails to build on Python 3.13 python-cffi/cffi#23 there is apparently a pre-release out - which does not do us much good.
  • Presumably a usable release will come eventually and this will just fix itself
• rather a lot of deprecation warnings for utcnow() via httpretty
  • httpretty looks kinda dead, that could be a problem at some point
• and some encoding warnings, presumably per Fix encoding warnings with PEP 597 enabled #8893

[radoering]

and some encoding warnings

Can you tell me where I see these warnings? I thought it should be visible for example in the Ubuntu Python 3.13 pytest job when I expand Run poetry run pytest --integration -v and scroll down but there is only a datetime warning. (Still wondering why I cannot find any warnings in #8893, cf #8893 (comment))

[dimbleby]

I might have mixed up poetry and poetry-core, PYTHONWARNDEFAULTENCODING is only turned on in poetry-core

eg in the poetry-core pull request https://github.com/python-poetry/poetry-core/actions/runs/9750266660/job/26909309129?pr=742

Run poetry run python -m pytest -p no:sugar --integration -q tests/integration
/home/runner/.local/share/pypoetry/venv/lib/python3.13/site-packages/poetry/utils/env/base_env.py:338: EncodingWarning: 'encoding' argument not specified.
output = subprocess.check_output(

but this is also true in the 3.12 test so perhaps nothing much to do with 3.13

[dimbleby]

re-ran following the release of cffi 1.17.0, pretty much working now.

Just one over-specified testcase that mysteriously is ever so slightly different on macos python 3.13.

[radoering]

Just one over-specified testcase that mysteriously is ever so slightly different on macos python 3.13.

I assume we should just make the test more robust to allow any order in the output because cleo, tomlkit and pendulum are all installed in parallel.

[dimbleby]

or, maybe, make the tests run with a worker pool of size one so that they are not exposed to this sort of thing

(I did take a brief look back in August and remember being puzzled as to what was going on, not expecting to try again though)

[poetry-bot]

The backport to 1.8 failed:

The process '/usr/bin/git' failed with exit code 1

To backport manually, run these commands in your terminal:

# Fetch latest updates from GitHub
git fetch
# Create a new working tree
git worktree add .worktrees/backport-1.8 1.8
# Navigate to the new working tree
cd .worktrees/backport-1.8
# Create a new branch
git switch --create backport-9523-to-1.8
# Cherry-pick the merged commit of this pull request and resolve the conflicts
git cherry-pick -x --mainline 1 6c43ac34b047f186006d5731e9119cbc2f03144d
# Push it to GitHub
git push --set-upstream origin backport-9523-to-1.8
# Go back to the original working tree
cd ../..
# Delete the working tree
git worktree remove .worktrees/backport-1.8

Then, create a pull request where the base branch is 1.8 and the compare/head branch is backport-9523-to-1.8.

[github-actions]

This pull request has been automatically locked since there has not been any recent activity after it was closed. Please open a new issue for related bugs.