Potential feature gaps when compared to the specs

[brettcannon]

I asked ChatGPT to make a table of features that we might be missing.

Specification	Covered by pypa/packaging?	Notes / Implementation if Not Covered
Names and normalization	✅ Yes	Implements PEP 503 via canonicalize_name() in packaging.utils 1
Core metadata specifications	✅ Yes	Implements metadata parsing/validation in packaging.metadata 2
Version specifiers (PEP 440)	✅ Yes	Provided via packaging.version and packaging.specifiers 1
Dependency specifiers (PEP 508)	✅ Yes	Provided via packaging.requirements and packaging.markers 2
pyproject.toml spec (PEPs 518/621)	❌ No (#647)	Handled by build backends (e.g. setuptools, Poetry); not parsed by packaging
Dependency Groups (PEP 735)	❌ No (#1065)	Requires separate library (e.g. dependency-groups); packaging is out of scope
Inline script metadata (PEP 723)	❌ No	For runtime script metadata; not a concern of packaging
Platform compatibility tags (PEP 425/600)	✅ Yes	Implements via packaging.tags 2
Well-known Project URLs (PEP 753)	❌ No	Normalised by index/pip; packaging only retains metadata as-is
Glob patterns	❌ No	Handled by build tools; no native glob support in packaging
License Expression (SPDX / PEP 639)	✅ Yes	Implemented through packaging.licenses 2
Recording installed projects (PEP 376)	❌ No	Managed by installers (e.g. pip); not within packaging scope
Entry points spec	❌ No	Handled by build backends and importlib.metadata; not by packaging
Direct URL origin/data (PEP 610)	❌ No (#944)	Recorded by installers (pip); not by packaging
Python Virtual Environments (PEP 405)	❌ No	Implemented in stdlib (venv) and virtualenv, not packaging
Externally Managed Environments (PEP 668)	❌ No	Policy enforced by installers/package managers; not in packaging
Source distribution format	⚠️ Partial	Filename parsing only (parse_sdist_filename()); no content handling
Binary distribution format (Wheel, PEP 427)	⚠️ Partial (#697)	Filename parsing (parse_wheel_filename()); no wheel creation/content handling 12
.pypirc file	❌ No	Configuration for uploads; in tools like twine/pip only
Simple repository API (PEP 503)	❌ No (#1088)	Only name normalization covered; metadata fetching handled by pip/Warehouse
File Yanking (PEP 592)	❌ No (#1088)	Handled by index and installer (pip); not in packaging
Index hosted attestations (PEP 658)	❌ No	Security metadata handled by index/installer; not in packaging
Project Status Markers (PEP 792)	❌ No (#1088)	Index metadata (e.g. deprecated); not in packaging
Python Description Formats	❌ No	Description content type stored but not rendered/validated
build-details.json (PEP 739)	❌ No	Generated by Python installer; read by build tools, not packaging
Reproducible Environments (beyond lock file)	❌ No	Covered by pip/Pipenv; only pylock.toml lock file is supported
pylock.toml spec (PEP 751)	✅ Yes	Supported in v26 through packaging.pylock
PyPA schemas	❌ No	JSON schemas for validation; code validation done instead of schema-based

[brettcannon]

My question is do we want to fill these holes if we can in a sans-I/O fashion?

[SpecLad]

FWIW, #920 implements a significant portion of "Recording installed projects".

[henryiii]

pyproject.toml spec is also #847, and I'm slowly working toward it (https://github.com/pypa/pyproject-metadata/releases/tag/0.11.0). Inline script metadata parsing seems simple to add too, I've added it in nox; I think you'd just want the regex to pick out the toml, and not the actual toml parsing. Wheel building #697 would be good too. Help for SDists, too, would be nice.

[notatallshaw]

I have a few random thoughts:

I'm positive on packaging providing more non-IO standards, even fairly simple stuff, it makes it easier for all sorts of tools to rely on packaging to get the specification right.

I have been considering adding yanking to packaging, it turns out there are two types of yanking implicitly defined by PEP 592 (pypa/pip#13755) file and release. And yanking a release ends up interacting with pre-releases 🫠, so it might make sense for Version objects to have a yanked bool for Specifier filtering.

With that said, packaging's API choices can end up having a big impact on consumers in a way that isn't always positive, and if we're adding a lot of new APIs we should be cognizant of this. For example:

• Specifier[Set].filter caused packaging users to write code in awkward ways (until #1066 was fixed).
• Reading large JSON files (such as the simple API response for boto3) in Python ends up consuming a lot of memory (pypa/pip#12834), so some users of packaging may want to apply iterative JSON parsers, but if packaging's API forces you to materialize the entire JSON in memory before passing it to packaging that could restrict innovation.

[edgarrmondragon]

fwiw I'd love to see Direct URL origin/data (PEP 610) in packaging.direct_url and archive https://github.com/edgarrmondragon/pep610/ 😄

[brettcannon]

packaging's API choices can end up having a big impact on consumers in a way that isn't always positive, and if we're adding a lot of new APIs we should be cognizant of this.

I agree with that sentiment and it should be something to keep in mind when consider API designs.