From Fedora Project Wiki
(Benefit to Fedora)
(Scope)
Line 113: Line 113:
== Scope ==
== Scope ==
* Proposal owners:
* Proposal owners:
# check there are really no more manual requirements with dots
# disable the automatically generated provides with dots when we update to Python 3.11
# double-check there are really no more manual requirements with dots
<!-- 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?-->


* Other developers: <!-- REQUIRED FOR SYSTEM WIDE CHANGES -->
* Other developers: <!-- REQUIRED FOR SYSTEM WIDE CHANGES -->
** stop adding new manual Python dist requirements with dots
<!-- 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/issues #Releng issue number] <!-- REQUIRED FOR SYSTEM WIDE CHANGES -->
* Release engineering: not needed for this Change <!-- REQUIRED FOR SYSTEM WIDE 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 -->


* Policies and guidelines: N/A (not needed for this Change) <!-- REQUIRED FOR SYSTEM WIDE CHANGES -->
* Policies and guidelines: they already only cover PEP 503 <!-- REQUIRED FOR SYSTEM WIDE CHANGES -->
<!-- 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. Please submit a pull request with the proposed changes before submitting your Change proposal. -->
<!-- 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. Please submit a pull request with the proposed changes before submitting your Change proposal. -->


* Trademark approval: N/A (not needed for this Change)
* Trademark approval: not needed for this Change
<!-- If your Change may require trademark approval (for example, if it is a new Spin), file a ticket ( https://pagure.io/Fedora-Council/tickets/issues ) requesting trademark approval from the Fedora Council. This approval will be done via the Council's consensus-based process. -->
<!-- If your Change may require trademark approval (for example, if it is a new Spin), file a ticket ( https://pagure.io/Fedora-Council/tickets/issues ) requesting trademark approval from the Fedora Council. This approval will be done via the Council's consensus-based process. -->


* Alignment with Objectives:  
* Alignment with Objectives: not really
<!-- Does your proposal align with the current Fedora Objectives: https://docs.fedoraproject.org/en-US/project/objectives/ ? It's okay if it doesn't, but it's something to consider -->
<!-- Does your proposal align with the current Fedora Objectives: https://docs.fedoraproject.org/en-US/project/objectives/ ? It's okay if it doesn't, but it's something to consider -->



Revision as of 17:28, 21 January 2022


Python Dist provides to only provide PEP503-complaint names

Summary

The legacy python3dist(NAME) and python3.11dist(NAME) RPM provides with dots (.) in NAME will no longer be automatically provided. NAME will only be normalized according to PEP 503. E.g. on Fedora 36 a package provides both python3dist(ruamel-yaml) and python3dist(ruamel.yaml), on Fedora 37+ it will only provide python3dist(ruamel-yaml) (and similarly, python3.11dist(ruamel-yaml).

Owner

Current status

  • Targeted release: Fedora Linux 37
  • Last updated: 2022-01-21
  • 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

This change is only about about automatic RPM provides in the following forms:

  • python3dist(NAME)
  • python3.Xdist(NAME)


It does not affect any other provides or package names.

Historically, Python package names were normalized by the RPM dependency generators in a way that diverged from upstream behavior. In upstream (e.g. when using pip) a package name with a dot is equal to a package name with a dash (e.g. pip install ruamel.yaml and pip install ruamel-yaml are equivalent). In Fedora, the Provides and Requires included the dot, but upstream rules defined in PEP 503 demand the dot to be replaced by a dash. This caused trouble when other packages required the packages via a name with a dash. Hence, we have slowly been migrating to PEP 503 name normalization.

  • Since Fedora 32, Python dependency generators have generated both variants of the Provides as a preparation for the transition to PEP 503-only.
  • Since Fedora 33, Python dependency generators have generated Requires in the PEP 503 form (no dots).
  • Only packages with manual BuildRequires, Requires, Recommends etc. with requirements such as python3dist(foo.bar) would be affected by this change. We have fixed all of them in Fedora 36.


Hence, together with the update to Python3.11, we will disable the legacy form of the provides.

Python packages with dots in their name will only provide the names with dashes.

RHEL/EPEL compatibility

This change is fully compatible with RHEL/EPEL 9, which behaves like Fedora 34 and hence has Provides in both forms but Requires in the PEP 503 form (no dots).

This change is not compatible with RHEL/EPEL 8. If you need to have manual requirements in the specfile that should work on Fedora 37+ and RHEL/EPEL 8 in this form and the name includes a dot, we recommend using %py3_dsit.

This change is not relevant to RHEL 7.

This change is not compatible with EPEL 7. If you need to have manual requirements in the specfile that should work on Fedora 37+ and RHEL/EPEL 7 in this form and the name includes a dot, we recommend using %py3_dsit.

Feedback

Benefit to Fedora

  • Less automatic provides in the repos - there are 93+93=186 provides like python3dist(x.y) and python3.Xdist(x.y) in rawhide today.
  • There will be only way way to express a Python package name in this context, not two.
  • One more thing the Python maintainers will cross off their TODO list.

Scope

  • Proposal owners:
  1. check there are really no more manual requirements with dots
  2. disable the automatically generated provides with dots when we update to Python 3.11
  3. double-check there are really no more manual requirements with dots
  • Other developers:
    • stop adding new manual Python dist requirements with dots
  • Release engineering: not needed for this Change
  • Policies and guidelines: they already only cover PEP 503
  • Trademark approval: not needed for this Change
  • Alignment with Objectives: not really

Upgrade/compatibility impact

How To Test

User Experience

Dependencies

Contingency Plan

  • Contingency mechanism: (What to do? Who will do it?) N/A (not a System Wide Change)
  • Contingency deadline: N/A (not a System Wide Change)
  • Blocks release? N/A (not a System Wide Change), Yes/No


Documentation

N/A (not a System Wide Change)

Release Notes