From Fedora Project Wiki
< Changes
No edit summary |
Churchyard (talk | contribs) |
||
| (13 intermediate revisions by 4 users not shown) | |||
| Line 15: | Line 15: | ||
* Name: [[User:Thrnciar|Tomáš Hrnčiar]] | * Name: [[User:Thrnciar|Tomáš Hrnčiar]] | ||
* Name: [[User:Churchyard|Miro Hrončok]] | * Name: [[User:Churchyard|Miro Hrončok]] | ||
* Name: [[User:lbalhar|Lumír Balhar]] | |||
<!-- Include you email address that you can be reached should people want to contact you about helping with your change, status is requested, or technical issues need to be resolved. If the change proposal is owned by a SIG, please also add a primary contact person. --> | <!-- Include you email address that you can be reached should people want to contact you about helping with your change, status is requested, or technical issues need to be resolved. If the change proposal is owned by a SIG, please also add a primary contact person. --> | ||
* Email: python-maint@redhat.com | * Email: python-maint@redhat.com | ||
| Line 20: | Line 21: | ||
* FESCo shepherd: [[User:FASAccountName| Shehperd name]] <email address> | * FESCo shepherd: [[User:FASAccountName| Shehperd name]] <email address> | ||
--> | --> | ||
== Current status == | == Current status == | ||
[[Category: | [[Category:ChangeAcceptedF39]] | ||
<!-- When your change proposal page is completed and ready for review and announcement --> | <!-- When your change proposal page is completed and ready for review and announcement --> | ||
<!-- remove Category:ChangePageIncomplete and change it to Category:ChangeReadyForWrangler --> | <!-- remove Category:ChangePageIncomplete and change it to Category:ChangeReadyForWrangler --> | ||
| Line 41: | Line 41: | ||
ON_QA -> change is fully code complete | ON_QA -> change is fully code complete | ||
--> | --> | ||
* FESCo issue: | * [https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org/thread/AHE5C5V2SAIJIIDWCRKMJPGFLRUCXJBC/ devel thread] | ||
* FESCo issue: [https://pagure.io/fesco/issue/2890 #2890] | |||
* Tracker bug: [https://bugzilla.redhat.com/show_bug.cgi?id=2135404 #2135404] | * Tracker bug: [https://bugzilla.redhat.com/show_bug.cgi?id=2135404 #2135404] | ||
* Release notes tracker: [ | * Release notes tracker: [https://pagure.io/fedora-docs/release-notes/issue/903 #903] | ||
== Detailed Description == | == Detailed Description == | ||
| Line 78: | Line 79: | ||
* 2023-07-19: Fedora 39 Mass Rebuild | * 2023-07-19: Fedora 39 Mass Rebuild | ||
** The mass rebuild happens with the fourth beta. We might need to rebuild Python packages later in exceptional case. | ** The mass rebuild happens with the fourth beta. We might need to rebuild Python packages later in exceptional case. | ||
** If the Koji side-tag is not merged yet at this point, we defer the change to Fedora | ** If the Koji side-tag is not merged yet at this point, we defer the change to Fedora 40. | ||
* 2023-07-31: Python 3.12.0 candidate 1 | * 2023-07-31: Python 3.12.0 candidate 1 | ||
** This serves as "final" for our purposes. | ** This serves as "final" for our purposes. | ||
| Line 108: | Line 109: | ||
== Benefit to Fedora == | == Benefit to Fedora == | ||
Fedora aims to showcase the latest in free and open-source software - we should have the most recent release of Python 3. Packages in Fedora can use the new features from 3. | Fedora aims to showcase the latest in free and open-source software - we should have the most recent release of Python 3. Packages in Fedora can use the new features from 3.12. | ||
<!-- What is the benefit to the platform? If this is a major capability update, what has changed? If this is a new functionality, what capabilities does it bring? Why will Fedora become a better distribution or project because of this proposal?--> | <!-- What is the benefit to the platform? If this is a major capability update, what has changed? If this is a new functionality, what capabilities does it bring? Why will Fedora become a better distribution or project because of this proposal?--> | ||
There's also a benefit to the larger Python ecosystem: by building Fedora's packages against 3. | There's also a benefit to the larger Python ecosystem: by building Fedora's packages against 3.12 while it's still in development, we can catch critical bugs before the final 3.12.0 release. | ||
== Scope == | == Scope == | ||
| Line 119: | Line 120: | ||
* Proposal owners: | * Proposal owners: | ||
<!-- What work do the feature owners have to accomplish to complete the feature in time for release? Is it a large change affecting many parts of the distribution or is it a very isolated change? What are those changes?--> | <!-- What work do the feature owners have to accomplish to complete the feature in time for release? Is it a large change affecting many parts of the distribution or is it a very isolated change? What are those changes?--> | ||
*# Introduce {{package|python3. | *# Introduce {{package|python3.12}} for all Fedoras | ||
*# Prepare stuff in Copr as explained in description. | *# Prepare stuff in Copr as explained in description. | ||
*# Update {{package|python-rpm-macros}} so {{package|python3. | *# Update {{package|python-rpm-macros}} so {{package|python3.12}} builds {{package|python3}} | ||
*# Build {{package|python3. | *# Build {{package|python3.12}} as the main Python | ||
*# Mass rebuild all the packages that runtime require `python(abi) = 3. | *# Mass rebuild all the packages that runtime require `python(abi) = 3.11` and/or `libpython3.11.so.1.0` (~3900 known packages in October 2022) | ||
*# Build {{package|python3. | *# Build {{package|python3.12}} as a non-main Python | ||
* Other developers: Maintainers of packages that fail to rebuild during the rebuilds will be asked, using e-mail and bugzilla, to fix or remove their packages from the distribution. If any issues appear, they should be solvable either by communicating with the respective upstreams first and/or applying downstream patches. Also, the package maintainers should have a look at: [https://docs.python.org/3. | * Other developers: Maintainers of packages that fail to rebuild during the rebuilds will be asked, using e-mail and bugzilla, to fix or remove their packages from the distribution. If any issues appear, they should be solvable either by communicating with the respective upstreams first and/or applying downstream patches. Also, the package maintainers should have a look at: [https://docs.python.org/3.12/whatsnew/3.12.html#porting-to-python-3-12 Porting to Python 3.12]. The python-maint team will be available to help with fixing issues. | ||
<!-- What work do other developers have to accomplish to complete the feature in time for release? Is it a large change affecting many parts of the distribution or is it a very isolated change? What are those changes?--> | <!-- What work do other developers have to accomplish to complete the feature in time for release? Is it a large change affecting many parts of the distribution or is it a very isolated change? What are those changes?--> | ||
* Release engineering: [ | * Release engineering: [TBD] <!-- REQUIRED FOR SYSTEM WIDE AS WELL AS FOR SELF CONTAINED CHANGES --> A targeted rebuild for all python packages will be required, before the mass rebuild. | ||
<!-- Does this feature require coordination with release engineering (e.g. changes to installer image generation or update package delivery)? Is a mass rebuild required? include a link to the releng issue. | <!-- Does this feature require coordination with release engineering (e.g. changes to installer image generation or update package delivery)? Is a mass rebuild required? include a link to the releng issue. | ||
The issue is required to be filed prior to feature submission, to ensure that someone is on board to do any process development work and testing, and that all changes make it into the pipeline; a bullet point in a change is not sufficient communication --> | The issue is required to be filed prior to feature submission, to ensure that someone is on board to do any process development work and testing, and that all changes make it into the pipeline; a bullet point in a change is not sufficient communication --> | ||
| Line 145: | Line 146: | ||
<!-- REQUIRED FOR SYSTEM WIDE CHANGES --> | <!-- REQUIRED FOR SYSTEM WIDE CHANGES --> | ||
All the packages that depend on Python 3 must be rebuilt. User written Python 3 scripts/applications may require a small amount of porting, but mostly Python 3.10 is | All the packages that depend on Python 3 must be rebuilt. User written Python 3 scripts/applications may require a small amount of porting, but mostly Python 3.11 is forward compatible with Python 3.12. | ||
=== The Python standard library distutils module will be removed === | |||
For many years distutils module was providing support for building and installing additional modules into a Python installation. | |||
Since Python 3.10 distutils package is deprecated, and will be removed in Python 3.12. Its functionality for specifying package builds has already been completely replaced by third-party packages setuptools and packaging, and most other commonly used APIs are available elsewhere in the standard library (such as platform, shutil, subprocess or sysconfig). | |||
Affected packages will be failing with `ModuleNotFoundError: No module named 'distutils'`. | |||
The python3-setutpools package provides a distutils module, so sometimes "simply" adding BuildRequires: python3-setuptools might workaround the problem. Unfortunately, it is not 100 % compatible with the removed standard library one distutils: https://github.com/pypa/setuptools/issues/3532 | |||
Fedora packagers can check if their packages build without distutils by removing it form Python 3.11: | |||
# `fedpkg clone <package name> && cd <package name>` | |||
# `mock -r fedora-rawhide-x86_64 init` | |||
# `mock -r fedora-rawhide-x86_64 install python3-devel` | |||
# `sudo rm -rf /var/lib/mock/fedora-rawhide-x86_64/root/usr/lib64/python3.11/distutils/` | |||
# `fedpkg mockbuild -N` | |||
Later, when [https://copr.fedorainfracloud.org/coprs/g/python/python3.12/ Python 3.12 COPR] is available, you can use it for testing. | |||
See https://lists.fedoraproject.org/archives/list/python-devel@lists.fedoraproject.org/thread/N6ITYHLRWIDNYNXGPYG2ZHF3ZLQWZN7L/ for known Fedora packages that'll need changes. | |||
=== pathfix.py tool will be removed === | |||
Since Python 2.0 (1994), Python provided a useful tool pathfix.py that we use in Python RPM macros for fixing shebangs of Python modules and some RPM packages use it as well directly in their specfiles for similar purposes. The script will no longer be part of [https://github.com/python/cpython/commit/e0ae9ddffe0a708d0d3f5b8cc10488d466fc43c4 CPython source code] and python3-devel RPM package. Because we think it's useful, we have decided to create a [https://github.com/fedora-python/pathfix new upstream project] for it on Github and [https://src.fedoraproject.org/rpms/python-rpm-macros/pull-request/150 include it in the python3-rpm-macros] package. The change means the script will move from `/usr/bin/pathfix.py` to `/usr/lib/rpm/redhat/pathfix.py`. The script will no longer be executable and it will need to be invoked via `%{python3}` or `/usr/bin/python3`. | |||
For users of `%py_shebang_fix` and `%py3_shebang_fix` no action is needed. The macros will soon use the new location of the tool. | |||
If you use the tool directly in your specfile a change is needed before Python 3.12 become the main one in Fedora 38. We have a list of affected packages and will open PRs for them soon. The list is also a part of the aforementioned PR for python-rpm-macros. | |||
See https://lists.fedoraproject.org/archives/list/python-devel@lists.fedoraproject.org/thread/XPWKHEJHWCJSOHKA6RZG3UYBJIKU6HB3/ | |||
== How To Test == | == How To Test == | ||
| Line 164: | Line 195: | ||
<!-- REQUIRED FOR SYSTEM WIDE CHANGES --> | <!-- REQUIRED FOR SYSTEM WIDE CHANGES --> | ||
Interested testers do not need special hardware. If you have a favourite Python 3 script, module, or application, please test it with Python 3. | Interested testers do not need special hardware. If you have a favourite Python 3 script, module, or application, please test it with Python 3.12 and verify that it still works as you would expect. If the application you are testing does not require any other modules, you can test it using {{package|python3.12}} even before this change is implemented, in Fedora 36, 37 or 38. | ||
In case your application requires other modules, or if you are testing an rpm package, it is necessary to install the 3. | In case your application requires other modules, or if you are testing an rpm package, it is necessary to install the 3.12 version of the python3 rpm. Right now that rpm is available in copr, along with all other python packages that build successfully with python 3.12. See https://copr.fedorainfracloud.org/coprs/g/python/python3.12/ for detailed instructions on how to enable Python 3.12 copr for mock. | ||
Once the change is in place, test if your favourite Python apps are working as they were before. File bugs if they don't. | Once the change is in place, test if your favourite Python apps are working as they were before. File bugs if they don't. | ||
| Line 182: | Line 213: | ||
--> | --> | ||
Regular distro users shouldn't notice any change in system behaviour other than the Python 3 interpreter will be in version 3. | Regular distro users shouldn't notice any change in system behaviour other than the Python 3 interpreter will be in version 3.12. | ||
== Dependencies == | == Dependencies == | ||
| Line 189: | Line 220: | ||
<!-- REQUIRED FOR SYSTEM WIDE CHANGES --> | <!-- REQUIRED FOR SYSTEM WIDE CHANGES --> | ||
4000+ packages depend on Python 3 and ~ | 4000+ packages depend on Python 3 and ~3900 packages need rebuilding when Python is upgraded. See scope section. | ||
== Contingency Plan == | == Contingency Plan == | ||
<!-- If you cannot complete your feature by the final development freeze, what is the backup plan? This might be as simple as "Revert the shipped configuration". Or it might not (e.g. rebuilding a number of dependent packages). If you feature is not completed in time we want to assure others that other parts of Fedora will not be in jeopardy. --> | <!-- If you cannot complete your feature by the final development freeze, what is the backup plan? This might be as simple as "Revert the shipped configuration". Or it might not (e.g. rebuilding a number of dependent packages). If you feature is not completed in time we want to assure others that other parts of Fedora will not be in jeopardy. --> | ||
* Contingency mechanism: Do not merge the side tag with rawhide. If the side tag has been merged and issues arise, that will justify a downgrade, then use an epoch tag to revert to 3. | * Contingency mechanism: Do not merge the side tag with rawhide. If the side tag has been merged and issues arise, that will justify a downgrade, then use an epoch tag to revert to 3.11 version (never needed before) <!-- REQUIRED FOR SYSTEM WIDE CHANGES --> | ||
<!-- When is the last time the contingency mechanism can be put in place? This will typically be the beta freeze. --> | <!-- When is the last time the contingency mechanism can be put in place? This will typically be the beta freeze. --> | ||
* Contingency deadline: TBD <!-- REQUIRED FOR SYSTEM WIDE CHANGES --> | * Contingency deadline: TBD <!-- REQUIRED FOR SYSTEM WIDE CHANGES --> | ||
<!-- Does finishing this feature block the release, or can we ship with the feature in incomplete state? --> | <!-- Does finishing this feature block the release, or can we ship with the feature in incomplete state? --> | ||
* Blocks release? Yes, we'd like to block Fedora | * Blocks release? Yes, we'd like to block Fedora 39 release on at least 3.12.0rc1 <!-- REQUIRED FOR SYSTEM WIDE CHANGES --> | ||
* Blocks product? See above <!-- Applicable for Changes that blocks specific product release/Fedora.next --> | * Blocks product? See above <!-- Applicable for Changes that blocks specific product release/Fedora.next --> | ||
| Line 205: | Line 236: | ||
<!-- REQUIRED FOR SYSTEM WIDE CHANGES --> | <!-- REQUIRED FOR SYSTEM WIDE CHANGES --> | ||
[https:// | [https://peps.python.org/pep-0693/ Python 3.12 Release Schedule] | ||
[https:// | [https://peps.python.org/pep-0693/#features-for-3-12 Features for 3.12] | ||
[https://docs.python.org/3. | [https://docs.python.org/3.12/whatsnew/3.12.html What's new in 3.12] | ||
[https://docs.python.org/3. | [https://docs.python.org/3.12/whatsnew/3.12.html#porting-to-python-3-12 Porting to Python 3.12] | ||
== Release Notes == | == Release Notes == | ||
Latest revision as of 21:33, 5 July 2023
Python 3.12
Summary
Update the Python stack in Fedora from Python 3.11 to Python 3.12, the newest major release of the Python programming language.
Owner
- Name: Tomáš Hrnčiar
- Name: Miro Hrončok
- Name: Lumír Balhar
- Email: python-maint@redhat.com
Current status
- Targeted release: Fedora Linux 39
- Last updated: 2023-07-05
- devel thread
- FESCo issue: #2890
- Tracker bug: #2135404
- Release notes tracker: #903
Detailed Description
We would like to upgrade Python to 3.12 in Fedora 39 thus we are proposing this plan early.
See the upstream notes at Features for 3.12 and What's new in 3.12.
Important dates and plan
- 2022-05-08: Python 3.12 development begins
- 2022-10-24: Python 3.12.0 alpha 1
- Package it as
python3.12 - Start the bootstrap procedure in Copr
- Do a mass rebuild against every future release in Copr
- Package it as
- 2022-11-14: Python 3.12.0 alpha 2
- 2022-12-05: Python 3.12.0 alpha 3
- 2023-01-09: Python 3.12.0 alpha 4
- 2023-02-06: Python 3.12.0 alpha 5
- 2023-02-07: Branch Fedora 38, Rawhide becomes future Fedora 39
- The earliest point when we can start rebuilding in Koji side-tag
- 2023-03-06: Python 3.12.0 alpha 6
- 2023-04-03: Python 3.12.0 alpha 7
- 2023-05-08: Python 3.12.0 beta 1
- No new features beyond this point
- 2023-05-29: Python 3.12.0 beta 2
- The ideal point when we can start rebuilding in Koji
- 2023-06-05: Expected side tag-merge (optimistic)
- 2023-06-19: Python 3.12.0 beta 3
- 2023-06-26: Expected side tag-merge (realistic)
- 2023-07-10: Python 3.12.0 beta 4
- 2023-07-17: Expected side tag-merge (pessimistic)
- 2023-07-19: Fedora 39 Mass Rebuild
- The mass rebuild happens with the fourth beta. We might need to rebuild Python packages later in exceptional case.
- If the Koji side-tag is not merged yet at this point, we defer the change to Fedora 40.
- 2023-07-31: Python 3.12.0 candidate 1
- This serves as "final" for our purposes.
- 2023-08-08: Branch Fedora 39, Rawhide becomes future Fedora 40
- 2023-08-08: Fedora 39 Change Checkpoint: Completion deadline (testable)
- 2023-08-22: Fedora Beta Freeze
- If rebuild with 3.12.0rc1 is needed, we should strive to do it before the freeze - there is a window of 3 weeks.
- 2023-09-04: Python 3.12.0 candidate 2
- 2023-09-12: Fedora 39 Beta Release (Preferred Target)
- Beta will likely be released with 3.12.0rc2.
- 2023-09-19: Fedora 39 Beta Target date #1
- 2023-10-02: Python 3.12.0 final
- 2023-10-03: Fedora 39 Final Freeze
- We'll update to 3.12.0 final using a freeze exception.
- 2023-10-17: Fedora 39 Preferred Final Target date
- 2023-10-24: Fedora 39 Final Target date #1
(From Python 3.12 Release Schedule and Fedora 39 Release Schedule.)
The schedule might appear somewhat tight for Fedora 39, but Python's annual release cycle was adapted for Fedora and this worked fine since Python 3.9 and Fedora 33. It is now common that Python is upgraded on a similar schedule in every odd-numbered Fedora release.
Note that upstream's "release candidates" are frozen except for blocker bugs. Since we can and will backport blocker fixes between Fedora and upstream, we essentially treat the Release Candidate as the final release.
Notes from the previous upgrade
There are notes from the previous upgrade available, so this upgrade may go smoother: SIGs/Python/UpgradingPython
Benefit to Fedora
Fedora aims to showcase the latest in free and open-source software - we should have the most recent release of Python 3. Packages in Fedora can use the new features from 3.12.
There's also a benefit to the larger Python ecosystem: by building Fedora's packages against 3.12 while it's still in development, we can catch critical bugs before the final 3.12.0 release.
Scope
We will coordinate the work in a side tag and merge when ready.
- Proposal owners:
- Introduce
- Prepare stuff in Copr as explained in description.
- Update
- Build
- Mass rebuild all the packages that runtime require
python(abi) = 3.11and/orlibpython3.11.so.1.0(~3900 known packages in October 2022) - Build
- Introduce
- Other developers: Maintainers of packages that fail to rebuild during the rebuilds will be asked, using e-mail and bugzilla, to fix or remove their packages from the distribution. If any issues appear, they should be solvable either by communicating with the respective upstreams first and/or applying downstream patches. Also, the package maintainers should have a look at: Porting to Python 3.12. The python-maint team will be available to help with fixing issues.
- Release engineering: [TBD] A targeted rebuild for all python packages will be required, before the mass rebuild.
- List of deliverables: nope
- Policies and guidelines: nope
- Trademark approval: nope
Upgrade/compatibility impact
All the packages that depend on Python 3 must be rebuilt. User written Python 3 scripts/applications may require a small amount of porting, but mostly Python 3.11 is forward compatible with Python 3.12.
The Python standard library distutils module will be removed
For many years distutils module was providing support for building and installing additional modules into a Python installation. Since Python 3.10 distutils package is deprecated, and will be removed in Python 3.12. Its functionality for specifying package builds has already been completely replaced by third-party packages setuptools and packaging, and most other commonly used APIs are available elsewhere in the standard library (such as platform, shutil, subprocess or sysconfig).
Affected packages will be failing with ModuleNotFoundError: No module named 'distutils'.
The python3-setutpools package provides a distutils module, so sometimes "simply" adding BuildRequires: python3-setuptools might workaround the problem. Unfortunately, it is not 100 % compatible with the removed standard library one distutils: https://github.com/pypa/setuptools/issues/3532
Fedora packagers can check if their packages build without distutils by removing it form Python 3.11:
fedpkg clone <package name> && cd <package name>mock -r fedora-rawhide-x86_64 initmock -r fedora-rawhide-x86_64 install python3-develsudo rm -rf /var/lib/mock/fedora-rawhide-x86_64/root/usr/lib64/python3.11/distutils/fedpkg mockbuild -N
Later, when Python 3.12 COPR is available, you can use it for testing.
See https://lists.fedoraproject.org/archives/list/python-devel@lists.fedoraproject.org/thread/N6ITYHLRWIDNYNXGPYG2ZHF3ZLQWZN7L/ for known Fedora packages that'll need changes.
pathfix.py tool will be removed
Since Python 2.0 (1994), Python provided a useful tool pathfix.py that we use in Python RPM macros for fixing shebangs of Python modules and some RPM packages use it as well directly in their specfiles for similar purposes. The script will no longer be part of CPython source code and python3-devel RPM package. Because we think it's useful, we have decided to create a new upstream project for it on Github and include it in the python3-rpm-macros package. The change means the script will move from /usr/bin/pathfix.py to /usr/lib/rpm/redhat/pathfix.py. The script will no longer be executable and it will need to be invoked via %{python3} or /usr/bin/python3.
For users of %py_shebang_fix and %py3_shebang_fix no action is needed. The macros will soon use the new location of the tool.
If you use the tool directly in your specfile a change is needed before Python 3.12 become the main one in Fedora 38. We have a list of affected packages and will open PRs for them soon. The list is also a part of the aforementioned PR for python-rpm-macros.
How To Test
Interested testers do not need special hardware. If you have a favourite Python 3 script, module, or application, please test it with Python 3.12 and verify that it still works as you would expect. If the application you are testing does not require any other modules, you can test it using 
python3.12
In case your application requires other modules, or if you are testing an rpm package, it is necessary to install the 3.12 version of the python3 rpm. Right now that rpm is available in copr, along with all other python packages that build successfully with python 3.12. See https://copr.fedorainfracloud.org/coprs/g/python/python3.12/ for detailed instructions on how to enable Python 3.12 copr for mock.
Once the change is in place, test if your favourite Python apps are working as they were before. File bugs if they don't.
User Experience
Regular distro users shouldn't notice any change in system behaviour other than the Python 3 interpreter will be in version 3.12.
Dependencies
4000+ packages depend on Python 3 and ~3900 packages need rebuilding when Python is upgraded. See scope section.
Contingency Plan
- Contingency mechanism: Do not merge the side tag with rawhide. If the side tag has been merged and issues arise, that will justify a downgrade, then use an epoch tag to revert to 3.11 version (never needed before)
- Contingency deadline: TBD
- Blocks release? Yes, we'd like to block Fedora 39 release on at least 3.12.0rc1
- Blocks product? See above
Documentation
Release Notes
- Migrating user installed packages - https://pagure.io/fedora-docs/release-notes/issue/503