Following system colour scheme Selected dark colour scheme Selected light colour scheme

Python Enhancement Proposals

Packaging PEPs

Introduction

This is the index of all Python Enhancement Proposals (PEPs) labelled under the ‘Packaging’ topic. This is a sub-index of PEP 0, the PEP index.

Packaging PEPs follow the PyPA specification update process. They are used to propose major additions or changes to the PyPA specifications. The canonical, up-to-date packaging specifications can be found on the Python Packaging Authority (PyPA) specifications page.

Index by Category

Meta-PEPs (PEPs about PEPs or Processes)

PEP Title Authors
PA 609 Python Packaging Authority (PyPA) Governance Dustin Ingram, Pradyun Gedam, Sumana Harihareswara

Provisional PEPs (provisionally accepted; interface may still change)

PEP Title Authors
SP 639 Improving License Clarity with Better Package Metadata Philippe Ombredanne, C.A.M. Gerlach, Karolina Surma
SP 708 Extending the Repository API to Mitigate Dependency Confusion Attacks Donald Stufft
SP 740 Index support for digital attestations William Woodruff, Facundo Tuesca, Dustin Ingram

Accepted PEPs (accepted; may not be implemented yet)

PEP Title Authors
SA 458 Secure PyPI downloads with signed repository metadata Trishank Karthik Kuppusamy, Vladimir Diaz, Marina Moore, Lukas Puehringer, Joshua Lock, Lois Anne DeLong, Justin Cappos
SA 625 Filename of a Source Distribution Tzu-ping Chung, Paul Moore
SA 658 Serve Distribution Metadata in the Simple Repository API Tzu-ping Chung
SA 668 Marking Python base environments as “externally managed” Geoffrey Thomas, Matthias Klose, Filipe Laíns, Donald Stufft, Tzu-ping Chung, Stefano Rivera, Elana Hashman, Pradyun Gedam
SA 685 Comparison of extra names for optional distribution dependencies Brett Cannon
SA 691 JSON-based Simple API for Python Package Indexes Donald Stufft, Pradyun Gedam, Cooper Lees, Dustin Ingram
SA 714 Rename dist-info-metadata in the Simple API Donald Stufft

Open PEPs (under consideration)

PEP Title Authors
S 480 Surviving a Compromise of PyPI: End-to-end signing of packages Trishank Karthik Kuppusamy, Vladimir Diaz, Justin Cappos, Marina Moore
S 694 Upload 2.0 API for Python Package Repositories Donald Stufft
S 710 Recording the provenance of installed packages Fridolín Pokorný
S 711 PyBI: a standard format for distributing Python Binaries Nathaniel J. Smith
S 725 Specifying external dependencies in pyproject.toml Pradyun Gedam, Ralf Gommers
S 735 Dependency Groups in pyproject.toml Stephen Rosen
S 739 Static description file for build details of Python installations Filipe Laíns 3.14
S 751 A file format to list Python dependencies for installation reproducibility Brett Cannon
S 752 Implicit namespaces for package repositories Ofek Lev
S 753 Uniform project URLs in core metadata William Woodruff, Facundo Tuesca
P 755 Implicit namespace policy for PyPI Ofek Lev
S 759 External Wheel Hosting Barry Warsaw, Ethan Smith

Finished PEPs (done, with a stable interface)

PEP Title Authors
SF 301 Package Index and Metadata for Distutils Richard Jones 2.3
SF 376 Database of Installed Python Distributions Tarek Ziadé 2.7, 3.2
SF 405 Python Virtual Environments Carl Meyer 3.3
SF 425 Compatibility Tags for Built Distributions Daniel Holth 3.4
SF 427 The Wheel Binary Package Format 1.0 Daniel Holth
SF 440 Version Identification and Dependency Specification Alyssa Coghlan, Donald Stufft
SF 503 Simple Repository API Donald Stufft
SF 508 Dependency specification for Python Software Packages Robert Collins
SF 517 A build-system independent format for source trees Nathaniel J. Smith, Thomas Kluyver
SF 518 Specifying Minimum Build System Requirements for Python Projects Brett Cannon, Nathaniel J. Smith, Donald Stufft
SF 527 Removing Un(der)used file types/extensions on PyPI Donald Stufft
SF 561 Distributing and Packaging Type Information Ethan Smith 3.7
SF 566 Metadata for Python Software Packages 2.1 Dustin Ingram 3.x
SF 592 Adding “Yank” Support to the Simple API Donald Stufft
SF 600 Future ‘manylinux’ Platform Tags for Portable Linux Built Distributions Nathaniel J. Smith, Thomas Kluyver
SF 610 Recording the Direct URL Origin of installed distributions Stéphane Bidoul, Chris Jerdonek
SF 621 Storing project metadata in pyproject.toml Brett Cannon, Dustin Ingram, Paul Ganssle, Pradyun Gedam, Sébastien Eustace, Thomas Kluyver, Tzu-ping Chung
SF 627 Recording installed projects Petr Viktorin
SF 629 Versioning PyPI’s Simple API Donald Stufft
SF 643 Metadata for Package Source Distributions Paul Moore
SF 656 Platform Tag for Linux Distributions Using Musl Tzu-ping Chung
SF 660 Editable installs for pyproject.toml based builds (wheel based) Daniel Holth, Stéphane Bidoul
SF 700 Additional Fields for the Simple API for Package Indexes Paul Moore
SF 715 Disabling bdist_egg distribution uploads on PyPI William Woodruff
SF 721 Using tarfile.data_filter for source distribution extraction Petr Viktorin 3.12
SF 723 Inline script metadata Ofek Lev

Historical Meta-PEPs and Informational PEPs

PEP Title Authors
PS 438 Transitioning to release-file hosting on PyPI Holger Krekel, Carl Meyer
PF 449 Removal of the PyPI Mirror Auto Discovery and Naming Scheme Donald Stufft
PF 464 Removal of the PyPI Mirror Authenticity API Donald Stufft
PF 470 Removing External Hosting Support on PyPI Donald Stufft
PF 541 Package Index Name Retention Łukasz Langa

Deferred PEPs (postponed pending further research or updates)

PEP Title Authors
ID 423 Naming conventions and recipes related to packaging Benoit Bryon
SD 491 The Wheel Binary Package Format 1.9 Daniel Holth

Abandoned, Withdrawn, and Rejected PEPs

PEP Title Authors
SS 241 Metadata for Python Software Packages A.M. Kuchling
SW 243 Module Repository Upload Mechanism Sean Reifschneider 2.1
SR 262 A Database of Installed Python Packages A.M. Kuchling
SS 314 Metadata for Python Software Packages 1.1 A.M. Kuchling, Richard Jones 2.5
SS 345 Metadata for Python Software Packages 1.2 Richard Jones 2.7
SR 365 Adding the pkg_resources module Phillip J. Eby
SW 381 Mirroring infrastructure for PyPI Tarek Ziadé, Martin von Löwis
SS 386 Changing the version comparison module in Distutils Tarek Ziadé
SR 390 Static metadata for Distutils Tarek Ziadé 2.7, 3.2
IR 396 Module Version Numbers Barry Warsaw
SR 402 Simplified Package Layout and Partitioning Phillip J. Eby 3.3
IW 426 Metadata for Python Software Packages 2.0 Alyssa Coghlan, Daniel Holth, Donald Stufft
SR 439 Inclusion of implicit pip bootstrap in Python installation Richard Jones 3.4
SW 459 Standard Metadata Extensions for Python Software Packages Alyssa Coghlan
IR 496 Environment Markers James Polley
IS 513 A Platform Tag for Portable Linux Built Distributions Robert T. McGibbon, Nathaniel J. Smith
SR 516 Build system abstraction for pip/conda etc Robert Collins, Nathaniel J. Smith
IS 571 The manylinux2010 Platform Tag Mark Williams, Geoffrey Thomas, Thomas Kluyver
SR 582 Python local packages directory Kushal Das, Steve Dower, Donald Stufft, Alyssa Coghlan 3.12
IS 599 The manylinux2014 Platform Tag Dustin Ingram
SS 631 Dependency specification in pyproject.toml based on PEP 508 Ofek Lev
SR 633 Dependency specification in pyproject.toml using an exploded TOML table Laurie Opperman, Arun Babu Neelicattu
SW 650 Specifying Installer Requirements for Python Projects Vikram Jayanthi, Dustin Ingram, Brett Cannon
SR 662 Editable installs via virtual wheels Bernát Gábor
SR 665 A file format to list Python dependencies for reproducibility of an application Brett Cannon, Pradyun Gedam, Tzu-ping Chung
SW 704 Require virtual environments by default for package installers Pradyun Gedam
SR 722 Dependency specification for single-file scripts Paul Moore

PEP Types Key

  • IInformational: Non-normative PEP containing background, guidelines or other information relevant to the Python ecosystem
  • PProcess: Normative PEP describing or proposing a change to a Python community process, workflow or governance
  • SStandards Track: Normative PEP with a new feature for Python, implementation change for CPython or interoperability standard for the ecosystem

More info in PEP 1.

PEP Status Key

  • AAccepted: Normative proposal accepted for implementation
  • AActive: Currently valid informational guidance, or an in-use process
  • DDeferred: Inactive draft that may be taken up again at a later time
  • <No letter>Draft: Proposal under active discussion and revision
  • FFinal: Accepted and implementation complete, or no longer active
  • PProvisional: Provisionally accepted but additional feedback needed
  • RRejected: Formally declined and will not be accepted
  • SSuperseded: Replaced by another succeeding PEP
  • WWithdrawn: Removed from consideration by sponsor or authors

More info in PEP 1.