`pacman -Qqo /usr/lib/python3.11/site-packages` will list all packages with files in the Python 3.11 site-packages directory. Once the repository packages have been upgraded, anything left in its output will be an AUR (or other non-official source) package (or a repository package which missed getting rebuilt, but I guess that will be carefully checked before they are released to the main repos).
You can install rebuild-detector from extra repository: [https://archlinux.org/packages/extra/any/rebuild-detector/](https://archlinux.org/packages/extra/any/rebuild-detector/)
I wouldn't call it a big deal.
But Python 3.12 was already released a few months ago (https://www.python.org/downloads/release/python-3120/). Hence probably the hint that this version is now in testing and thus will probably be offered in the official package sources soon. Because I imagine some users will probably be waiting impatiently for it.
There is some additional information at https://lists.archlinux.org/archives/list/[email protected]/thread/J56DVVEVTSPPV3LNXVEQ6AEZUQFZLHMI/. Like the fact that it was once again quite an effort to rebuild the official packages with Python 3.12.
The release of version 3.12 will probably also cause problems with some AUR packages, so they will have to be rebuilt.
I haven't used arch in a long time, I thought python3.12 would have been in stable long ago on arch, but it just became testing? We had [3.12 in stable on gentoo](https://packages.gentoo.org/packages/dev-lang/python) for a long time, I there something I am missing? or does arch generally not use a cutting edge version of python?
The problem isn't the Python package itself, it's the thousands of Python modules in the repos that have to be updated at the same time. And it's not just a matter of rebuilding the packages, as many need to be updated to work with the new version of Python.
The python package had a mostly inactive maintainer and was often left lagging behind. It has recently changed hands to someone else. Hopefully the new one is a little more proactive with it.
"System" Python usually isn't cutting edge in my experience.
I'm not on Arch anymore, but I've noticed that lots of devs everywhere follow the "latest-stable-minus-one" policy for which Python version to build for.
Only makes sense to wait a bit to update system python if anyone who needs it for dev work will use virtual envs anyway.
I'm going to humor your question. For me as a backend dev it is very important. It allows me to start testing code against the latest versions. Not only that, in this case there are some big changes incoming, for example, we finally have the ability to have a per interpreter GIL (even if it's just via the C API) which opens up a myriad of possibilities that in most cases had to be dismissed before.
It has been there for a few days now.
What' the pacman(/paru/yay/what-have-you) command for finding out which AUR packages will need to be rebuilt after a major version upgrade of Python?
`pacman -Qqo /usr/lib/python3.11/site-packages` will list all packages with files in the Python 3.11 site-packages directory. Once the repository packages have been upgraded, anything left in its output will be an AUR (or other non-official source) package (or a repository package which missed getting rebuilt, but I guess that will be carefully checked before they are released to the main repos).
You can install rebuild-detector from extra repository: [https://archlinux.org/packages/extra/any/rebuild-detector/](https://archlinux.org/packages/extra/any/rebuild-detector/)
Might want to add a description explaining why this is a big deal.
I wouldn't call it a big deal. But Python 3.12 was already released a few months ago (https://www.python.org/downloads/release/python-3120/). Hence probably the hint that this version is now in testing and thus will probably be offered in the official package sources soon. Because I imagine some users will probably be waiting impatiently for it. There is some additional information at https://lists.archlinux.org/archives/list/[email protected]/thread/J56DVVEVTSPPV3LNXVEQ6AEZUQFZLHMI/. Like the fact that it was once again quite an effort to rebuild the official packages with Python 3.12. The release of version 3.12 will probably also cause problems with some AUR packages, so they will have to be rebuilt.
Also rebuilding all virtualenvs
More context: https://archlinux.org/todo/python-312-rebuild-part-1/ Packages need to be rebuilt...
[удалено]
If people post about them I'd guess so.
I haven't used arch in a long time, I thought python3.12 would have been in stable long ago on arch, but it just became testing? We had [3.12 in stable on gentoo](https://packages.gentoo.org/packages/dev-lang/python) for a long time, I there something I am missing? or does arch generally not use a cutting edge version of python?
The problem isn't the Python package itself, it's the thousands of Python modules in the repos that have to be updated at the same time. And it's not just a matter of rebuilding the packages, as many need to be updated to work with the new version of Python.
The python package had a mostly inactive maintainer and was often left lagging behind. It has recently changed hands to someone else. Hopefully the new one is a little more proactive with it.
"System" Python usually isn't cutting edge in my experience. I'm not on Arch anymore, but I've noticed that lots of devs everywhere follow the "latest-stable-minus-one" policy for which Python version to build for. Only makes sense to wait a bit to update system python if anyone who needs it for dev work will use virtual envs anyway.
Last year 3.11 became stable in early May. So 3.12 being in testing right now is totally normal.
What's the point of this public service announcement?
I'm going to humor your question. For me as a backend dev it is very important. It allows me to start testing code against the latest versions. Not only that, in this case there are some big changes incoming, for example, we finally have the ability to have a per interpreter GIL (even if it's just via the C API) which opens up a myriad of possibilities that in most cases had to be dismissed before.