Skip to content

Conversation

rgommers
Copy link
Contributor

@rgommers rgommers commented Sep 3, 2025

This also references PEP 804 (see gh-4572), which address one of the most significant open issues about external dependency names needing to be curated and have canonical versions, rather than accepting everything that parses as a valid package URL. Hence these two PEPs now cross-reference each other. PEP 725 contains the packaging metadata, and PEP 804 the machinery and process around how that metadata is curated and can be queried, mapped, etc.

  • Change is either:
    • To a Draft PEP
    • To an Accepted or Final PEP, with Steering Council approval
    • To fix an editorial issue (markup, typo, link, header, etc)
  • PR title prefixed with PEP number (e.g. PEP 123: Summary of changes)

Cc'ing co-authors: @pradyunsg @jaimergp


📚 Documentation preview 📚: https://pep-previews--4573.org.readthedocs.build/

This also references PEP 804, which address one of the most significant
open issues about external dependency names needing to be curated
and have canonical versions, rather than accepting everything that
parses as a valid package URL. Hence these two PEPs now cross-reference
each other. PEP 725 contains the packaging metadata, and PEP 804
the machinery and process around how that metadata is curated and
can be queried, mapped, etc.
@rgommers
Copy link
Contributor Author

rgommers commented Sep 3, 2025

I know that rendering will fail because PEP 804 (just submitted in gh-4572) isn't yet merged, hence :pep:`804` references make the build unhappy. If the editors have another preference for handling this, like note using :pep: at all and putting that back later, please let me know.

@hugovk
Copy link
Member

hugovk commented Sep 3, 2025

One option is to wait for PEP 804 to get merged. Or if you don't want to wait that long, perhaps something like this, and revert once 804 is merged:

-and record such choices, is the topic of :pep:`804`.
+and record such choices, is the topic of `PEP 804`_.

+.. _PEP 804: https://github.com/python/peps/pull/4572

We'd have to see what the build thinks about Requires: 804.

Ralf Gommers <ralf.gommers@gmail.com>
Discussions-To: https://discuss.python.org/t/31888
Status: Draft
Type: Standards Track
Topic: Packaging
Requires: 804
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

If this 725 requires 804, and 804 requires 725, do they both need to be approved as a single unit?

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Good question. Not necessarily, although the text would need a few tweaks if PEP 725 gets approved and PEP 804 doesn't. PEP 725 makes sense without 804 in principle though. Vice versa not so much. You can have the metadata (725) without a central registry of canonical names (804), that works just fine - it just gets more free-form.

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

We should probably drop Requires here, since we have a reference in the "Motivation" section already.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Okay, will do. I only added it last-minute because Jaime asked about it for PEP 804, and it seems sensible to use it consistently between the two PEPs. Usage in other PEPs of this Requires field seems fairly rare and inconsistent anyway.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I removed this line now.

@rgommers
Copy link
Contributor Author

rgommers commented Sep 3, 2025

One option is to wait for PEP 804 to get merged. Or if you don't want to wait that long, perhaps something like this, and revert once 804 is merged:

I'm fine with waiting, we plan to open the Discourse threads in parallel anyway. If we'd space them too far apart, it's likely that comments on one PEP will be posted anyway on the thread for the other PEP.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

3 participants