PyPA 路线图¶

A status page for the major PyPA Todo items that will determine the course of Python Packaging.

Core Standards¶

Last Reviewed: 2020-06-08
Summary: Major upgrades of the metadata format. Version 1.2 was specified in PEP 345. PEP 426 is in Withdrawn status; it had a very broad scope, and included “build_requires” and “test_requires”, and the extensions system.
PEP Src: pep-0426-core-metadata.rst
Issues/PRs: pypa/interoperability-peps/labels/PEP426
Status: PEP 566 (Metadata 1.3) was accepted in February 2018. PEP 566 (Metadata 2.1) was accepted in February 2018. Several features of Metadata 2.0 are specified but not yet accepted or implemented.

Last Reviewed: 2017-12-10
Summary: An update to the notion of “Environment Markers” introduced in PEP 345. PEP 426 was originally scoped to include this update, but it was moved out to PEP 496.
PEP Src: pep-0496-environment-markers.rst
Issues/PRs: pypa/interoperability-peps/labels/PEP496
Status: PEP 496 has been rejected in favor of the more comprehensive PEP 508.

Last Reviewed: 2017-12-10
Summary: An attempt to formalize the notion of “Extras” introduced by setuptools. PEP 426 was originally scoped to include this, but it will likely be broken out.
Issues/PRs: pypa/interoperability-peps/labels/Extras
Status: Currently covered in PEP 426 (which is in Deferred status), but will likely be broken out.

Last Reviewed: 2017-12-10
Summary: A system that supports extending metadata with custom metadata. PEP 426 was originally scoped to include this. It’s unclear, if it will remain, or be broken out.
Issues/PRs: pypa/interoperability-peps/labels/Extensions
Status: Currently covered in PEP 426 (which is in Deferred status), but may be broken out.

Last Reviewed: 2017-12-10
Summary: Assuming we support an extensions system, then this describes a set of standard extensions for Python packages. This is currently specified in PEP 459.
PEP Src: pep-0459-standard-metadata-extensions.rst
Issues/PRs: pypa/interoperability-peps/labels/PEP459
Status: PEP 459 is in Deferred status.

Last Reviewed: 2017-12-10
Summary: An attempt to specify a tool-neutral Build API, that pip will adopt, with the goal being to easily support other build systems besides setuptools/distutils.
Issues/PRs: pypa/interoperability-peps/labels/Build-Neutrality
Status: Discussions are ongoing on distutils-sig. Some proposals involve solutions that solve sdist 2.0 and build neutrality with a single plan. There is also some debate whether to initially support neutrality using setup.py as the interface, or to use something completely new.

Last Reviewed: 2017-12-10
Summary: A specification for a new sdist format. The current setuptools sdist format has no formal specification. It’s up for debate whether this new format will be numbered “1.0” or “2.0”.
Issues/PRs: pypa/interoperability-peps/labels/sdist-2.0
Status: Discussions are ongoing on distutils-sig. Some proposals involve solutions that solve sdist 2.0 and build neutrality with a single plan. A central part of the discussion is whether sdists should (or can) be required to hold static metadata (vs. requiring a build command to generate the metadata).

Last Reviewed: 2017-12-10
Summary: An update to the “dist-info” installation database format introduced in PEP 376.
Issues/PRs: pypa/interoperability-peps/labels/Installation-Database
Status: No current activity.

Last Reviewed: 2017-12-10
Summary: An update to the wheel spec (PEP 427) largely to handle a tagging scheme for linux binary wheels, although there are various other issues that people have raised.
Issues/PRs: pypa/interoperability-peps/labels/Wheel
Status: No current activity.

Last Reviewed: 2017-12-10
Summary: This would be a replacement for PEP 425 that increases scope to also cover the naming scheme used for dist-info directories, installation DB metadata directories, sdist archives and wheel archives.
Issues/PRs: pypa/interoperability-peps/issues/48
Status: No current activity.

Last Reviewed: 2020-06-08
Summary: pip currently has an overly-simplistic “first found, wins” resolver that ignores constraints already present in the environment.
Issues/PRs: pip/issues/988
Status: The Packaging Working Group of the Python Software Foundation successfully applied for funding to finish the overhaul of the resolver, and a team is working on the project. A pip release including the new resolver is expected in 2020.

Last Reviewed: 2017-12-10
Summary: Many pip users want a non-recursive upgrade (pip upgrade -U is currently recursive), and many users also want some sort of pip upgrade --all command.
Issues/PRs: pip/issues/59
Status: Ongoing discussion in pip/issues/59. A non-recursive implementation of pip upgrade exists in pip/pull/3194

Last Reviewed: 2017-12-10
Summary: Possibly “vendor” a copy of distutils into setuptools, so that setuptools is free to evolve independent of the Standard Library copy of distutils.
Issues/PRs: setuptools/issues/417/adopt-distutils
Status: Under consideration.

Last Reviewed: 2020-06-08
Summary: An effort to integrate PyPI with the “The Update Framework” (TUF). This is specified in PEP 458
PEP Src: pep-0458-tuf-online-keys.rst
Issues/PRs: pypa/interoperability-peps/labels/PEP458
Status: PEP 458 is in Accepted status. The PSF’s Packaging Working Group received funding from Facebook and a team is currently working on implementing TUF on PyPI.

Last Reviewed: 2017-12-10
Summary: An attempt to improve the 2 primary PyPUG tutorials for readability and style, to coincide with the launch of the new Warehouse-backed PyPI.
Issues/PRs: warehouse/issues/729
Status: Nicole (from Warehouse team) and Marcus are working together on this along with a team of volunteer writers; see pypa/python-packaging-user-guide/tree/master/source/tutorials.

Last Reviewed: 2017-12-10
Summary: An attempt to present finalized PEPs as non-numbered “Specifications” that are organized together in the PyPUG. As it is, it’s too hard to know what really represents the finalized set of PyPA PEPs.
Issues/PRs: pypa.io/issues/11
Status: Nick Coghlan has started working on migrating to this approach, using pypa.io/specifications/ as the stable base URL.

Last Reviewed: 2017-12-10
Summary: At its core, PyPA is consistent with the Python PEP process, but around the edges, it has a unique workflow that should be documented, with the goal being to increase involvement. This process may change if the Python PEP database migrates to using GitLab as specified in PEP 507.
Issues/PRs: interoperability-peps/issues/53
Status: This is being worked on in conjunction with the Specs vs PEPs work.

Last Reviewed: 2020-07-20
Summary: PEP 609 suggests a governing model that aims to formalize existing practices.
Status: PEP 609 is approved. The PyPA and the Steering Council will continue to discuss and refine the scope of the PEP process, how and when it applies to packaging-specific standards and architecture decisions, and how we all might adapt governance processes further.