On 4/18/24 9:56 AM, Jelle van der Waa wrote:
Hi all,

We are almost ready to drop Python 3.12 in testing, hopefully tensorflow can be pursued-ed to recompile against [staging] soon.

This Python release dropped the `imp` module, but the next release (3.13) which is slated for October this year will drop more Python batteries, some methods and some unittest invocations. [1]

I already scanned a part of the Python packages and the mailcap and cgi deprecation will be a bit painful. (And logger.warn usage but that is easy to patch to logger.warning)

I want to propose to open issues per package for Python 3.13 compatibility, it would point out what is not compatible and ideally link to an upstream issue or let the package maintainer create this issue.

Once we are ready to start thinking about a Python 3.13 rebuild we can go through the list of issues with a `python-3.13` label. [2]

Finding issues now will hopefully:
a) convince packages we maintain to get a new release
b) a happier rebuild
c) find packages which are issues and should likely not be maintained in the repos

There is one caveat, the changelog is draft. I am not sure if Python has a history of reverting breaking changes in an alpha release. But as far as I know these things have been deprecated for quite a while.

We have a history of not opening upstream issues in our packaging repository, but I think for this scenario it would make sense and actually help us deliver Python sooner in the repos.

[1] https://docs.python.org/3.13/whatsnew/3.13.html
[2] https://gitlab.archlinux.org/groups/archlinux/packaging/packages/-/issues

Greetings,

Jelle van der Waa


In general this sounds good to me. Even if these deprecations are not being dropped in python 3.13 would there be any harm in already opening issues to push for removal of these deprecated parts?

Best regards
Segaja

Attachment: OpenPGP_signature.asc
Description: OpenPGP digital signature

Reply via email to