PEP 804: version 2, address all feedback received so far #4749
Conversation
| ``python3-`` prefix. Additional details are available in `Debian's Python Policy <https://www.debian.org/doc/packaging-manuals/python-policy/#module-package-names>`__. | ||
|
|
||
| Gentoo follows a similar approach to naming Python packages, using the ``dev-python/`` | ||
| category and some `well-specified rules <https://projects.gentoo.org/python/guide/package-maintenance.html>`__. |
There was a problem hiding this comment.
Strictly speaking we also suffer from having some Python packages in other categories, particularly when they are also apps or parts of apps.
|
@pradyunsg, can you take a look here whenever you have the time? Thanks! 🙏 |
| The mapping infrastructure has been designed to present the following components and properties: | ||
|
|
||
| - A central registry of PEP 725 identifiers (DepURLs), including at least the |
There was a problem hiding this comment.
This list is almost identical to another list a few paragraphs below; it seems unnecessary to have both.
| Specification | ||
| ============= | ||
|
|
There was a problem hiding this comment.
There's a large amount of repetition and overlap between the upper "central registry", "mappings", and "known ecosystems" sections, and the corresponding sections within "schema details". However, neither of them is complete in itself, so getting a full understanding requires constant scrolling back and forth.
Suggest unifying these into a single specification by merging the upper sections with the "schema details" sections, so that "Specification" would have only 3 child sections.
The table restructuring suggested in my other comment would help give some space where the extra content can go. Even more space could be made by removing the "required" column in favor of a marker inside the "Field" column, e.g. "name (required)". However some material may still be more appropriate to keep outside of the tables, as paragraphs above or below.
| Each entry in this list is defined as a dictionary with these fields: | ||
|
|
||
| .. list-table:: |
There was a problem hiding this comment.
The package_managers table has very tall narrow columns which are difficult to read. This isn’t so bad in the GitHub rendering, but peps.python.org has much narrower pages. Suggest splitting commands and specifier_syntax out into separate tables.
| - Short identifier for this package manager (usually the command name). | ||
| - True | ||
| * - ``commands`` | ||
| - ``dict[Literal['install', 'query'], dict[Literal['command', 'requires_elevation', 'multiple_specifiers'], list[str] | bool | Literal['always', 'name-only', 'never']]]`` |
There was a problem hiding this comment.
These complex type annotations aren't really readable in this form. Suggest simplifying to dict.
| A collection of example mappings for a sample of packages can be found at `external-metadata-mappings <https://github.com/jaimergp/external-metadata-mappings/tree/main/data>`__. | ||
| For (3), the JSON Schema is defined at `known-ecosystems.schema.json <https://github.com/jaimergp/external-metadata-mappings/blob/main/schemas/known-ecosystems.schema.json>`__. | ||
| An example list can be found at `known-ecosystems.json <https://github.com/jaimergp/external-metadata-mappings/blob/main/data/known-ecosystems.json>`__. | ||
| The JSON Schemas are created with `these Pydantic models <https://github.com/jaimergp/external-metadata-mappings/blob/main/schemas/schema.py>`__. |
| ------------------------------------------------ | ||
| Some ecosystems have their own variants of known packages; e.g. Debian's | ||
| ``libsymspg2-dev``. While an identifier such as ``dep:debian/libsymspg2-dev`` |
There was a problem hiding this comment.
Should be dep:deb/debian/libsymspg2-dev: see the PURL spec.
3 participants
PEP 123: Summary of changes)cc'ing co-authors: @rgommers @pradyunsg @mgorny @msarahan
📚 Documentation preview 📚: https://pep-previews--4749.org.readthedocs.build/