From Fedora Project Wiki
(Initial change)
 
m (Add BZ tracker)
 
(8 intermediate revisions by 4 users not shown)
Line 1: Line 1:
{{DISPLAYTITLE:Changes/No more automagic Python bytecompilation (phase 2)}}


<!-- Self Contained or System Wide Change Proposal?
<!-- Self Contained or System Wide Change Proposal?
Line 58: Line 59:
CLOSED as NEXTRELEASE -> change is completed and verified and will be delivered in next release under development
CLOSED as NEXTRELEASE -> change is completed and verified and will be delivered in next release under development
-->
-->
* Tracker bug: <will be assigned by the Wrangler>
* Tracker bug: [https://bugzilla.redhat.com/show_bug.cgi?id=1626685 #1626685]


== Detailed Description ==
== Detailed Description ==
Line 66: Line 67:
We will now set <code>%_python_bytecompile_extra</code> to <code>0</code> by default.
We will now set <code>%_python_bytecompile_extra</code> to <code>0</code> by default.


All packages that ship Python 3 bytecode oustide of Python 3 directories should be preferably converted to the new style fo doing things, but if they are not, it's fine.
All packages that ship Python 3 bytecode outside of Python 3 directories should be preferably converted to use <code>%py_byte_compile</code>, but if they are not, it's fine.


We'll check all pyc/pyo files shipped by packages. We'll check if those are explicitly done the new way. If not, we mass push `%global _python_bytecompile_extra 1` to the package specs to make them working. It's up the package maintainers to adjust the package to the new style, (or keep the line forever).
We'll check all pyc/pyo files shipped by packages. We'll check if those are explicitly compiled using <code>%py_byte_compile</code>. If not, we mass push `%global _python_bytecompile_extra 1` to the package specs to make them work. It's up the package maintainers to adjust the package to the new style (or keep the line forever).


== Benefit to Fedora ==
== Benefit to Fedora ==
Line 83: Line 84:
<!-- 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: [https://pagure.io/releng/issue/XXX #XXX] (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/issue/7680 #7680] (a check of an impact with Release Engineering is needed) <!-- REQUIRED FOR SYSTEM WIDE AS WELL AS FOR SELF CONTAINED CHANGES -->
<!-- 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 150: Line 151:
This change does not deserve Release Notes, it is not user facing.
This change does not deserve Release Notes, it is not user facing.


[[Category:ChangePageIncomplete]]
[[Category:ChangeAcceptedF30]]
<!-- 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 21:20, 7 September 2018



No more automagic Python bytecompilation (phase 2)

Summary

See Changes/No_more_automagic_Python_bytecompilation. Now we are changing the default to be %global _python_bytecompile_extra 0.

Owner

Current status

Detailed Description

See the Detailed Description of the previous Change Proposal.

We will now set %_python_bytecompile_extra to 0 by default.

All packages that ship Python 3 bytecode outside of Python 3 directories should be preferably converted to use %py_byte_compile, but if they are not, it's fine.

We'll check all pyc/pyo files shipped by packages. We'll check if those are explicitly compiled using %py_byte_compile. If not, we mass push %global _python_bytecompile_extra 1 to the package specs to make them work. It's up the package maintainers to adjust the package to the new style (or keep the line forever).

Benefit to Fedora

See Changes/No_more_automagic_Python_bytecompilation#Benefit_to_Fedora.


Scope

  • Proposal owners: Change the default, slightly change the guidelines, get the list of packages, push the change into them.
  • Other developers: Maintainers of python3 packages are encouraged to change their packages to use explicit %py_byte_compile (not a System Wide Change, they don't have to do anything).
  • Release engineering: #7680 (a check of an impact with Release Engineering is needed)
  • Policies and guidelines: will be changed as described in description
  • Trademark approval: not needed

Upgrade/compatibility impact

None expected.

How To Test

N/A

User Experience

The users of this change are packagers. The new behavior should make byte-compilation more obvious, explicit, and discoverable. Users of Fedora should not feel this (except if this change uncovers a packaging bug).

Contingency Plan

  • Contingency mechanism: we'll finish the change later (not a System Wide Change)
  • Contingency deadline: none (not a System Wide Change)
  • Blocks release? no (not a System Wide Change)
  • Blocks product? no

Documentation

The guidelines will be the documentation.

Release Notes

This change does not deserve Release Notes, it is not user facing.