Python 3.13 specific packaging issues
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
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
Excerpts from Jelle van der Waa's message of abril 18, 2024 4:56 am:
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 was hit by the imp removal today. Made a PR against the upstream project. I think that, to cover our bases, we should open issues on upstream projects using the (soon to be) deprecated modules and as well to python project itself. If one has also time to make PR's, better. But we know how some upstream can be slow to act, so we will certainly need some patching. Regards, Giancarlo Razzolini
On 4/22/24 10:26 PM, Giancarlo Razzolini wrote:
Excerpts from Jelle van der Waa's message of abril 18, 2024 4:56 am:
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 was hit by the imp removal today. Made a PR against the upstream project.
I think that, to cover our bases, we should open issues on upstream projects using the (soon to be) deprecated modules and as well to python project itself.
If one has also time to make PR's, better. But we know how some upstream can be slow to act, so we will certainly need some patching.
Regards, Giancarlo Razzolini
Just to be sure, `importlib.util.spec_from_file_location()` is unchanged correct? I've read the change log up and down a couple of times, and it appears to only affect the `imp` lib specifically and I think I've covered my bases. But just for my own sanity, have I correctly understood the change in 3.13 in my above reasoning? Otherwise I will be guilty of issues in `archinstall` since I use `importlib.util` quite heavily. //Anton
Excerpts from Anton Hvornum's message of abril 23, 2024 2:06 pm:
Just to be sure, `importlib.util.spec_from_file_location()` is unchanged correct? I've read the change log up and down a couple of times, and it appears to only affect the `imp` lib specifically and I think I've covered my bases.
But just for my own sanity, have I correctly understood the change in 3.13 in my above reasoning? Otherwise I will be guilty of issues in `archinstall` since I use `importlib.util` quite heavily.
Relevant docks on the imp removal and alternatives [0]. Also, for reference, the PR I made against the upstream project to fix imp's removal issue [1]. Looks like the most affect imp function is load_source(), as there's no direct replacement for it on importlib. [0] https://docs.python.org/3/whatsnew/3.12.html#imp [1] https://github.com/enkore/i3pystatus/pull/865/ Regards, Giancarlo Razzolini
On 4/23/24 8:11 PM, Giancarlo Razzolini wrote:
Just to be sure, `importlib.util.spec_from_file_location()` is unchanged correct? I've read the change log up and down a couple of times, and it appears to only affect the `imp` lib specifically and I think I've covered my bases.
But just for my own sanity, have I correctly understood the change in 3.13 in my above reasoning? Otherwise I will be guilty of issues in `archinstall` since I use `importlib.util` quite heavily. Relevant docks on the imp removal and alternatives [0]. Also, for reference,
Excerpts from Anton Hvornum's message of abril 23, 2024 2:06 pm: the PR I made against the upstream project to fix imp's removal issue [1].
Looks like the most affect imp function is load_source(), as there's no direct replacement for it on importlib.
[0] https://docs.python.org/3/whatsnew/3.12.html#imp [1] https://github.com/enkore/i3pystatus/pull/865/
Regards, Giancarlo Razzolini
Thank you! I appear to follow their recommendations [0] with the slight exception of ignoring the explicit loader, as I've chosen to fail if no loader could be automatically found. It could perhaps be worth noting that when we do help out or migrate existing code from `imp`, we (and I) should explicitly `import importlib.util` as it is not exposed in `importlib/__init__.py` by default. But is commonly exposed through other libraries such as `matplotlib` through their existence alone on the system [1]. [0] https://github.com/archlinux/archinstall/blob/beeb9d7fde8db7ed0dc9fb10cf7eec... [1] https://discuss.python.org/t/python3-11-importlib-no-longer-exposes-util/256... //Anton
On 18-04-2024 09:56, 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.
Since no objects were raised, I have started creating issues under the `python::3.13` label. https://gitlab.archlinux.org/groups/archlinux/packaging/packages/-/issues/?l...
participants (4)
-
Andreas 'Segaja' Schleifer
-
Anton Hvornum
-
Giancarlo Razzolini
-
Jelle van der Waa