From Fedora Project Wiki
(Benefit to Fedora section)
No edit summary
 
(11 intermediate revisions by the same user not shown)
Line 19: Line 19:


<!-- The actual name of your proposed change page should look something like: Changes/Your_Change_Proposal_Name.  This keeps all change proposals in the same namespace -->
<!-- The actual name of your proposed change page should look something like: Changes/Your_Change_Proposal_Name.  This keeps all change proposals in the same namespace -->
= Eliminate the python- prefix from the Python 2 package names and /usr/bin/python from shebangs =
 
{{admon/important|Draft|This page is a Draft and it's content was added to [[FinalizingFedoraSwitchtoPython3]]  }}
 
= Use explicit version of Python 2/3 throughout Fedora=


== Summary ==
== Summary ==


With Python 2 approaching it's EOL, we are trying to prepare Fedora for a transition to Python 3 as default, so that <code>python</code> without a version number means Python 3. This Fedora change is the first step on the way to achieving this.
Currently, in Fedora package names, executables etc., <code>python</code> without a version number generally means Python 2. Given that the upstream support for Python 2 will end soon, we want to prepare Fedora for a transition to Python 3. Before switching <code>python</code> to refer to Python 3, we need to free it of the current meaning of Python 2. This means explicitly using either "python2" or "python3" throughout Fedora.
 
This Fedora change is "Phase 1" of a long-term effort described in [[FinalizingFedoraSwitchtoPython3|Finalizing Fedora's Switch to Python 3]]  transition plan.


== Owner ==
== Owner ==
<!--
 
For change proposals to qualify as self-contained, owners of all affected packages need to be included here. Alternatively, a SIG can be listed as an owner if it owns all affected packages.
This should link to your home wiki page so we know who you are.
-->
* Name: [[User:Ishcherb| Iryna Shcherbina]]
* Name: [[User:Ishcherb| Iryna Shcherbina]]
<!-- 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. -->
* Name: [[User:Churchyard| Miro Hrončok]]
* Email: ishcherb@redhat.com
* Name: [[User:Pviktori| Petr Viktorin]]
* Email: python-maint at redhat.com
* Release notes owner: <!--- To be assigned by docs team [[User:FASAccountName| Release notes owner name]] <email address> -->
* Release notes owner: <!--- To be assigned by docs team [[User:FASAccountName| Release notes owner name]] <email address> -->
<!--- UNCOMMENT only for Changes with assigned Shepherd (by FESCo)
* FESCo shepherd: [[User:FASAccountName| Shehperd name]] <email address>
-->
<!--- UNCOMMENT only if this Change aims specific product, working group (Cloud, Workstation, Server, Base, Env & Stacks)
* Product:
* Responsible WG:
-->


== Current status ==
== Current status ==
Line 57: Line 53:
== Detailed Description ==
== Detailed Description ==


[[FinalizingFedoraSwitchtoPython3|Finalizing Fedora's Switch to Python 3]] document provides detailed information on the matter. This Fedora change covers only [[FinalizingFedoraSwitchtoPython3#Phase_1:_Eliminate_the_python-_prefix_from_the_Python_2_package_names_and_.2Fusr.2Fbin.2Fpython_from_shebangs|Phase 1]] of the transition steps, and aims to clean up Fedora packages in accordance with recent changes to [[Packaging:Python|Python packaging guidelines]] regarding the usage of <code>python</code> without a version number in package names, requirements, shebangs, etc. The clean up covers:
This Change covers:


* Renaming Python 2 binary RPMs from <code>python-foo</code> to <code>python2-foo</code>
* Renaming Python 2 binary RPMs from <code>python-foo</code> to <code>python2-foo</code>
Line 63: Line 59:


* Fixing ambiguous Python 2 dependency declarations, i.e using <code>python2-foo</code> instead of <code>python-foo</code> in requirements
* Fixing ambiguous Python 2 dependency declarations, i.e using <code>python2-foo</code> instead of <code>python-foo</code> in requirements
We have started opening automatic Pull Requests with patches as announced in [https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org/thread/EJ5XP2R54V62K7FD5DIPQS3ZYKPUIULH/ Mass Pull Request filing for ambiguous Python 2 requirements].  The packages which will be targeted are tracked in [http://fedora.portingdb.xyz/namingpolicy/#require-misnamed PortingDB].
We have started opening automatic Pull Requests with patches as announced in [https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org/thread/EJ5XP2R54V62K7FD5DIPQS3ZYKPUIULH/ Mass Pull Request filing for ambiguous Python 2 requirements].  The packages which will be targeted are tracked in [http://fedora.portingdb.xyz/namingpolicy/#require-misnamed PortingDB] (at this point, most of these fail to build due to unrelated problems).


* Ensuring that <code>/usr/bin/python</code> or <code>/usr/bin/env python</code> shebangs are replaced with either <code>/usr/bin/python2</code> or <code>/usr/bin/python3</code>
* Start ensuring that <code>/usr/bin/python</code> or <code>/usr/bin/env python</code> shebangs are replaced with either <code>/usr/bin/python2</code> or <code>/usr/bin/python3</code>
This is currently covered by a Taskotron check. We will provide a macro to do this automatically, and help packagers do the change.


Each of the above conforms to the [[Packaging:Python|Python packaging guidelines]] as approved by FPC. The work on the change is already in progress and will be tracked by this Fedora change.


Each of the above steps conforms to the [[Packaging:Python|Python packaging guidelines]] and was approved by FPC. The work on the change is already in progress and will be tracked by this Fedora change.
== Benefit to Fedora ==


== Benefit to Fedora ==
This transition plan will simplify the final transition to Python 3 when the upstream support for Python 2 ends.


See [[FinalizingFedoraSwitchtoPython3#Benefit_to_Fedora|Benefit to Fedora section in the Finalizing Fedora's Switch to Python 3]] document.
Fedora has long been a one of the leaders of the ''Make Python 3 the Default Python'' initiative, having Python 3 as the "default Python" since Fedora 23 including a Fedora Workstation without Python 2, [http://fedora.portingdb.xyz/ tracking the status of Python 3 compatibility] and actively getting involved in porting upstream projects, such as (but not limited to) Samba. However, there are other distros (such as Arch) where <code>python</code> means Python 3 for quite some time.


== Scope ==
== Scope ==
* Proposal owners:
* Proposal owners:
Proposal owners are to communicate the idea to the packagers and rename the affected packages as well as fix the requirements via [[Mass_package_changes]] procedure.


* Other developers: N/A (not a System Wide Change) <!-- REQUIRED FOR SYSTEM WIDE CHANGES -->
* Other developers:
<!-- 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?-->
Package maintainers are expected to fix package requirements generated from shebangs by making sure that no scripts in their packages use <code>/usr/bin/python</code> or <code>/usr/bin/env python</code> shebangs.
Package maintainers will also be asked to review Pagure PRs with automated patches fixing the ambiguous Python 2 dependency declarations.


* Release engineering: [https://pagure.io/releng/issues #Releng issue number] (a check of an impact with Release Engineering is needed) <!-- REQUIRED FOR SYSTEM WIDE AS WELL AS FOR SELF CONTAINED CHANGES -->
* Release engineering: [https://pagure.io/releng/issues #Releng issue number] (a check of an impact with Release Engineering is needed) <!-- REQUIRED FOR SYSTEM WIDE AS WELL AS FOR SELF CONTAINED CHANGES -->
Line 86: Line 86:
<!-- Please check the list of Fedora release deliverables and list all the differences the feature brings -->
<!-- Please check the list of Fedora release deliverables and list all the differences the feature brings -->


* Policies and guidelines: N/A (not a System Wide Change) <!-- REQUIRED FOR SYSTEM WIDE CHANGES -->
* Policies and guidelines:
<!-- Do the packaging guidelines or other documents need to be updated for this feature?  If so, does it need to happen before or after the implementation is done?  If a FPC ticket exists, add a link here. -->
** Using python2/python3 instead of python in binary RPM package name [https://fedoraproject.org/wiki/Packaging:Naming?rd=Packaging:NamingGuidelines#Python2_binary_package_naming guidelines], [https://pagure.io/packaging-committee/issue/685 fpc] (already in effect)
 
** Using python2/python3 instead of python in (Build)Requires, [https://fedoraproject.org/wiki/Packaging:Python#Dependencies guidelines], [https://pagure.io/packaging-committee/issue/686 fpc] (already in effect)
* Trademark approval: N/A (not needed for this Change)
** Using <code>/usr/bin/python2</code> instead of <code>/usr/bin/python</code> in shebangs and Requires, [https://fedoraproject.org/wiki/User:Churchyard/Packaging:Python#Multiple_Python_Runtimes guidelines], [https://pagure.io/packaging-committee/issue/698 fpc] (already in effect)
<!-- If your Change may require trademark approval (for example, if it is a new Spin), file a ticket ( https://fedorahosted.org/council/ ) requesting trademark approval from the Fedora Council. This approval will be done via the Council's consensus-based process. -->
 
== Upgrade/compatibility impact ==
<!-- What happens to systems that have had a previous versions of Fedora installed and are updated to the version containing this change? Will anything require manual configuration or data migration? Will any existing functionality be no longer supported? -->
 
<!-- REQUIRED FOR SYSTEM WIDE CHANGES -->
N/A (not a System Wide Change)  


== How To Test ==
== How To Test ==
<!-- This does not need to be a full-fledged document. Describe the dimensions of tests that this change implementation is expected to pass when it is done.  If it needs to be tested with different hardware or software configurations, indicate them.  The more specific you can be, the better the community testing can be.
Remember that you are writing this how to for interested testers to use to check out your change implementation - documenting what you do for testing is OK, but it's much better to document what *I* can do to test your change.
A good "how to test" should answer these four questions:


0. What special hardware / data / etc. is needed (if any)?
We have implemented taskotron checks for these changes. The checks are being run each time a Python package is build in Koji, and you may view the results in [https://taskotron.fedoraproject.org/resultsdb/results?testcases=dist.python-versions taskotron resultsdb] or when you submit the update in Bodhi.
1. How do I prepare my system to test this change? What packages
need to be installed, config files edited, etc.?
2. What specific actions do I perform to check that the change is
working like it's supposed to?
3. What are the expected results of those actions?
-->
 
<!-- REQUIRED FOR SYSTEM WIDE CHANGES -->
N/A (not a System Wide Change)
 
== User Experience ==
<!-- If this change proposal is noticeable by its target audience, how will their experiences change as a result?  Describe what they will see or notice. -->
<!-- REQUIRED FOR SYSTEM WIDE CHANGES -->
N/A (not a System Wide Change)


== Dependencies ==
== Dependencies ==
Line 125: Line 99:


<!-- REQUIRED FOR SYSTEM WIDE CHANGES -->
<!-- REQUIRED FOR SYSTEM WIDE CHANGES -->
N/A (not a System Wide Change)
None


== 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.  -->
* Contingency mechanism: All changes are incremental. If a part of the Change is not completed in time, it will be moved to the next Fedora release.
* Contingency mechanism: (What to do?  Who will do it?) N/A (not a System Wide Change)  <!-- REQUIRED FOR SYSTEM WIDE CHANGES -->
* Contingency deadline: beta freeze
<!-- When is the last time the contingency mechanism can be put in place?  This will typically be the beta freeze. -->
* Blocks release? No
* Contingency deadline: N/A (not a System Wide Change)  <!-- REQUIRED FOR SYSTEM WIDE CHANGES -->
* Blocks product? No
<!-- Does finishing this feature block the release, or can we ship with the feature in incomplete state? -->
* Blocks release? N/A (not a System Wide Change), Yes/No <!-- REQUIRED FOR SYSTEM WIDE CHANGES -->
* Blocks product? product <!-- Applicable for Changes that blocks specific product release/Fedora.next -->


== Documentation ==
== Documentation ==
<!-- Is there upstream documentation on this change, or notes you have written yourself?  Link to that material here so other interested developers can get involved. -->
* [[FinalizingFedoraSwitchtoPython3]]
 
* [https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org/thread/6AIJ6CYUYXACKR4TJH2ATY2JYWSHPRSG/ Discussion on Fedora devel mailing list]
<!-- REQUIRED FOR SYSTEM WIDE CHANGES -->
* [https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org/thread/DQ4VMCKFO7I5ZVRDTGEMISG6LG7P7BM7/#Q225ZPP7R5OAI6MWDW7D5HUNMPIFV3EI Mass package change (python2- binary package renaming), part 1]
N/A (not a System Wide Change)
* [https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org/thread/JBLBDFGQJZ5ZDNXPKW5CHNTWGEQ2YTYJ/ MASS CHANGE announcement: python2- prefix renaming, part 2]
* [https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org/thread/EJ5XP2R54V62K7FD5DIPQS3ZYKPUIULH/ Mass Pull Request filing for ambiguous Python 2 requirements].


== Release Notes ==
== Release Notes ==
Line 149: Line 121:
Release Notes are not required for initial draft of the Change Proposal but has to be completed by the Change Freeze.  
Release Notes are not required for initial draft of the Change Proposal but has to be completed by the Change Freeze.  
-->
-->
TBD


[[Category:ChangePageIncomplete]]
<!-- [[Category:ChangePageIncomplete]] -->
<!-- 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 -->

Latest revision as of 11:21, 5 January 2018


Important.png
Draft
This page is a Draft and it's content was added to FinalizingFedoraSwitchtoPython3

Use explicit version of Python 2/3 throughout Fedora

Summary

Currently, in Fedora package names, executables etc., python without a version number generally means Python 2. Given that the upstream support for Python 2 will end soon, we want to prepare Fedora for a transition to Python 3. Before switching python to refer to Python 3, we need to free it of the current meaning of Python 2. This means explicitly using either "python2" or "python3" throughout Fedora.

This Fedora change is "Phase 1" of a long-term effort described in Finalizing Fedora's Switch to Python 3 transition plan.

Owner

Current status

  • Targeted release: Fedora 28
  • Last updated: 2018-01-05
  • Tracker bug: <will be assigned by the Wrangler>

Detailed Description

This Change covers:

  • Renaming Python 2 binary RPMs from python-foo to python2-foo

This is already partially done by applying automated patches as announced in Mass package change (python2- binary package renaming). The packages which still need to be fixed are tracked in PortingDB.

  • Fixing ambiguous Python 2 dependency declarations, i.e using python2-foo instead of python-foo in requirements

We have started opening automatic Pull Requests with patches as announced in Mass Pull Request filing for ambiguous Python 2 requirements. The packages which will be targeted are tracked in PortingDB (at this point, most of these fail to build due to unrelated problems).

  • Start ensuring that /usr/bin/python or /usr/bin/env python shebangs are replaced with either /usr/bin/python2 or /usr/bin/python3

This is currently covered by a Taskotron check. We will provide a macro to do this automatically, and help packagers do the change.

Each of the above conforms to the Python packaging guidelines as approved by FPC. The work on the change is already in progress and will be tracked by this Fedora change.

Benefit to Fedora

This transition plan will simplify the final transition to Python 3 when the upstream support for Python 2 ends.

Fedora has long been a one of the leaders of the Make Python 3 the Default Python initiative, having Python 3 as the "default Python" since Fedora 23 including a Fedora Workstation without Python 2, tracking the status of Python 3 compatibility and actively getting involved in porting upstream projects, such as (but not limited to) Samba. However, there are other distros (such as Arch) where python means Python 3 for quite some time.

Scope

  • Proposal owners:

Proposal owners are to communicate the idea to the packagers and rename the affected packages as well as fix the requirements via Mass_package_changes procedure.

  • Other developers:

Package maintainers are expected to fix package requirements generated from shebangs by making sure that no scripts in their packages use /usr/bin/python or /usr/bin/env python shebangs. Package maintainers will also be asked to review Pagure PRs with automated patches fixing the ambiguous Python 2 dependency declarations.

  • Policies and guidelines:
    • Using python2/python3 instead of python in binary RPM package name guidelines, fpc (already in effect)
    • Using python2/python3 instead of python in (Build)Requires, guidelines, fpc (already in effect)
    • Using /usr/bin/python2 instead of /usr/bin/python in shebangs and Requires, guidelines, fpc (already in effect)

How To Test

We have implemented taskotron checks for these changes. The checks are being run each time a Python package is build in Koji, and you may view the results in taskotron resultsdb or when you submit the update in Bodhi.

Dependencies

None

Contingency Plan

  • Contingency mechanism: All changes are incremental. If a part of the Change is not completed in time, it will be moved to the next Fedora release.
  • Contingency deadline: beta freeze
  • Blocks release? No
  • Blocks product? No

Documentation

Release Notes

TBD