From Fedora Project Wiki
(First draft of a change proposal)
 
m (Add how to test + link to the pull request)
Line 41: Line 41:
   
   
== Scope ==
== Scope ==
* Proposal owners: Change the brp-python-bytecompile script and macros in redhat-rpm-config package, help with transforming the packages.
* Proposal owners: Change the brp-python-bytecompile script and macros in redhat-rpm-config package, help with transforming the packages. See https://src.fedoraproject.org/rpms/redhat-rpm-config/pull-request/87


* Other developers: Maintainers of the mentioned python packages will have to change their packages to use explicit <code>%py_byte_compile</code> <!-- REQUIRED FOR SYSTEM WIDE CHANGES -->
* Other developers: Maintainers of the mentioned python packages will have to change their packages to use explicit <code>%py_byte_compile</code> <!-- REQUIRED FOR SYSTEM WIDE CHANGES -->
Line 55: Line 55:


== How To Test ==
== How To Test ==
N/A
Build a package with <code>%global _python_bytecompile_extra 1</code>. The build should fail with an actionable error message.


== User Experience ==
== User Experience ==

Revision as of 11:31, 20 May 2020

No more automagic Python bytecompilation (phase 3)

Summary

See Changes/No_more_automagic_Python_bytecompilation and Changes/No_more_automagic_Python_bytecompilation_phase_2. Now, %global _python_bytecompile_extra 1 won't be allowed anymore and raises an error with a link to this change.

Owner

Current status

  • Targeted release: Fedora 33
  • Last updated: 2020-05-20
  • FESCo issue: <will be assigned by the Wrangler>
  • Tracker bug: <will be assigned by the Wrangler>
  • Release notes tracker: <will be assigned by the Wrangler>

Detailed Description

See the Detailed Description of the previous Change Proposal and the Detailed Description of its phase 2.

Currently, Fedora rawhide contains ~130 packages with %global _python_bytecompile_extra 1 in their specfiles but surprisingly only 42 of them actually ship any .pyc files outside the standard location /usr/lib(64)?/python[0-9]\.[0-9]+. That might be caused by either of the following:

  • there is nothing to byte-compile — the statement is a leftover to be removed
  • The automagic bytecompilation uses /usr/bin/python by default (for historical reasons) but /usr/bin/python is not present in the buildroot by default.

Our plan is to finish the announced removal of this automagic Python bytecompilation, remove it from packages where it's not necessary and fix it with %py_byte_compile for packages where it's needed.

The documentation already contains the following paragraph:

If you have *.py files outside of the /usr/lib(64)?/pythonX.Y/ directories and you require those files to be byte compiled (e.g. it’s an importable Python module) you MUST compile them explicitly using the %py_byte_compile macro. Note that not all Python files are importable Python modules; when in doubt, grep the sources for the appropriate import statement.

so no changes have to be made there.

Benefit to Fedora

More explicit specfiles when it comes to Python byte compilation. This change also supports the dropping of unversioned %{__python} macro.

Scope

  • Other developers: Maintainers of the mentioned python packages will have to change their packages to use explicit %py_byte_compile
  • Release engineering: No Release engineering work is needed for this change
  • Policies and guidelines: nothing to be changed
  • Trademark approval: not needed

Upgrade/compatibility impact

None expected.

How To Test

Build a package with %global _python_bytecompile_extra 1. The build should fail with an actionable error message.

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: revert the changes in redhat-rpm-config
  • Contingency deadline: none (not a System Wide Change)
  • Blocks release? no (not a System Wide Change)
  • Blocks product? no

Documentation

The guidelines already contain up-to-date documentation.

Release Notes

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