python 3.13 in workflows
time to find out what is broken at python 3.13
could be worse:
- failure to install on macos
- looks like the problem is
cffi - per https://github.com/python-cffi/cffi/issues/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
- looks like the problem is
- rather a lot of deprecation warnings for
utcnow()viahttpretty-
httprettylooks kinda dead, that could be a problem at some point
-
- and some encoding warnings, presumably per https://github.com/python-poetry/poetry/pull/8893
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 https://github.com/python-poetry/poetry/pull/8893#issuecomment-2132228330)
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
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.
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.
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)
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.
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.