We are trying to migrate our existing application from Python 3.9 to Python 3.11 . We observed that RPM’s for following Python packages are not available for Python 3.11.
iotop - Installed by iotop-0.6-30.el9.noarch RPM
nftables - installed by python3-nftables-1.0.4-10.el9_1.x86_64 RPM
These RPM’s are installing only for Python 3.9 and RPM’s for Python 3.11 are not available. Python 3.11 RPM package are available for few of Python packages. e.g.
Default system python is 3.9, so dependencies won’t change for this. You can use python3.11, but the operating system will still need python3.9 for system-related stuff and this will not change for the entirety of Rocky 9.x - even future versions.
Rocky is based on RHEL, so it is the same as RHEL. If RHEL don’t change/update their package versions, Rocky won’t see those updates either. Rocky will not digress from package versions as Rocky aims to be 1:1 with RHEL.
The OS has “platform python” that – as said – will remain same until EOL of the distro.
There are alternative python versions (e.g. the 3.11) for user applications.
There are some modules (e.g. numpy) as RPM for each available python version, so that all users do not have to fetch all modules for their own needs (e.g. with pip install --user or venv).
The dnf, nft, iotop, etc are system applications that run with the platform python and hence stick to that version.
If, for example, the package manager (dnf) would be shifted to depend on 3.11 now, then it would have to be shifted to 3.11+x relatively soon. IMHO, such frequent porting would be wasted effort and expose dnf to “novel bugs”. If the package management, firewall, and whatnot of distro are eaten by bugs, then nobody is happy …
Python 3.11 and the upcoming release of Python 3.12 in 9.4 are for maintenance/development work due to “breaking changes”, the removal of depreciated functions".
I agree that default Python version for Rocky Linux 9.2 will remain at 3.9 and 3.11 package are made available through appstream only.
I just want to confirm that RPM packages for mentioned Python packages are not provided by Rocky Linux itself. As 3.11 version RPM packages are available for few of Python packages
Also I hope we can install metntioned package through tarball on system. Please let me know if there is any other alternatives.
sh-5.1# pip3 install nftables
ERROR: Could not find a version that satisfies the requirement nftables (from versions: none)
ERROR: No matching distribution found for nftables
When I trace back for Python 3.9. I found that it’s installed through python3-nftables RPM package.
This sounds like an XY problem. You’ve asked X (involving package support for 3.11 and system packages like nftables), solving for Y (which you’ve not sufficiently answered; migrating an application is not the answer). What is it that you’re actually trying to achieve by using python 3.11 alongside nftables, selinux, and subscription manager?
Why does your application need python 3.11 when the system default (which everything on the system relies on) is 3.9?
Apologies if it was confusing. I listed those Python 3.9 packages and am checking their availability in Python 3.11 as part of migration effort. Hence, I posted this query. I will try to explore how these packages are actually used in my application
We are trying to move to 3.11 as latest Python release in security status. As 3.9 will be EOL in 2025-10
Python 3.9 will be remain default python on Rocky Linux 9. Even beyond the end of life date, python 3.9 will be here to stay. Trying to force system utilities and libraries to use a newer python will cause various issues, if not break your system.
Standalone applications that need a newer python can use python 3.11 (and python 3.12 when it is released with rocky linux 9.4). There should be no expectation, however, of being able to hook into the system packages/libraries in python3.11 as it is not the default python.
Upstream Python 3.9 will EOL 2025-10. RHEL 9/Rocky 9 Python “3.9” will EOL 2032-05 and will be kept secure all the way.
The “Python 3.9” in RHEL 9 is not the upstream version. It is something that was forked from upstream version by Red Hat into separate branch that is maintained by RH with backports: https://access.redhat.com/solutions/57665
One simply does not mess with the core components (like nftable) of Enterprise Linux. If one does, the result is no more EL, will probably break, and you can keep the pieces (preferably isolated from all networks).
Even though RHEL 9 will keep maintain Python 3.9 until 2032, most python packages will not do the same. Quite some packages already dropped Python 3.7, and based on past experience, their support for Python 3.9 will also be dropped soon after its EOL in 2025. My feeling is that in recent years, Python and its ecosystem evolve much faster, and sticking to one version for 10 years is getting harder and harder.
I used to copy .spec from Fedora and build my own python39-XXX rpms on Rocky 8. With Rocky 9, doing so for Python 3.11 or 3.12 is a bit more diffcult as Redhat changed their policy on supporting non-default Python versions. For example, as stated in this thread, switching the system-default python would cause issues (and DNF is just recently changed to hard-coding python3.9 instead of python3). I wonder if using venv+pip would be a more viable solution.
On assumption that most user applications are not in RPM-packages and do have their own requirements for what Python modules they do use, I’d say “yes”. Up to distinct venv for each application. IMHO, in worst case via conda.