Would it be possible for us to include within the original PEP when the acceptance date was? Currently that is not specified on that page, which makes it difficult to reason about timelines.
1 Like
I’m happy to add it, but don’t think that I should do so unless someone can provide clarity on how this is typically notated, if at all. I don’t see an appropriate field in the PEP headers, so it seems like this isn’t usually done? If that’s the case, I’m unclear on how or why this change is special.
There should be a link to the (dated) acceptance post. That’s the normal approach - is it not sufficient?
The last date in the Post-History field should also be pretty close to the acceptance date (since it should correspond to the discussion where the acceptance occurred).
You only see that date if you open up the link to this thread. IMHO the info should be available within the PEP itself, to be self contained.
The last date in the
Post-Historyfield should also be pretty close to the acceptance date (since it should correspond to the discussion where the acceptance occurred).
Post-History:
14-Nov-2023, 20-Nov-2023
Was accepted on 2024-October 10th. So a whole 11 months later. Proving this is not the case.
1 Like
We can add the acceptance post to the Post-History, but obviously that won’t be reliable because if you check the history for some other PEP, you won’t have any such guarantee. I’ll put in the PR for that because I think it’s nice for the last post to be the acceptance independent of this issue.
This sounds to me like a reasonable field to want in the headers – as a coarse equivalent to which CPython version added a feature (Python-Version). i.e. Accepted: '2024-10-10 <link>'.
But again, I don’t want to make this change just to one PEP given – that feels like it’s overstepping my role. I’m happy to do the legwork to add this to a bunch of accepted packaging PEPs if the field is defined.
Should we move this to a fresh thread to discuss adding a field for the packaging PEPs to allow an Accepted date field? Or is there something very particular to 735 which makes it the first / only / most-relevant case to discuss?
I haven’t seen this discussed on past PEPs, which is leaving me feeling a little confused about why it’s coming up only in this thread.
2 Likes
The PEP does not spell it out explicitly, but I gather from the fact that the intent is to not involve any build backend that the dependency groups cannot be dynamic, yes PEP 621 – Storing project metadata in pyproject.toml | peps.python.org?
I think this should be a proposal for the PEP process as a whole. I don’t think there’s anything special about packaging PEPs (much less this specific PEP) here.
4 Likes
The “dynamic” field only contains project subkeys. Dependency groups are a top-level key, so they aren’t allowed in dynamic, as you say.
I would disagree. Python PEPs have an available in release, that is an implicit-accepted date built into it. Packaging PEPs do not have that, so it’s more important to have their acceptance date. That being said, I would find it nice to have it for all PEPs.
3 Likes
4 Likes
There has been a push to avoid referring to end users to PEPs as these can be technical and difficult to understand. Instead, we should encourage people to read Python Packaging User Guide
Accordingly, would it be possible to document the PEP there without the technical jargon? We should establish some kind of best practice here, that post PEP acceptance the PEP author(s) should fill this user PR too, or part of the PEP?
2 Likes
Sorry, I should have made that point when accepting. You’re absolutely right, one of the post-acceptance tasks is to document the new feature in the “PyPA Specifications” section of the packaging user guide. @sirosen can you add that to the list of things you need to do, please?
2 Likes
tox from version 4.22.0 (just released) supports dependency groups as defined in the recently accepted PEP 735 – Dependency Groups in pyproject.toml | peps.python.org see Configuration - tox
6 Likes
I think this makes tox the first project to add support for this pep! Congrats 
4 Likes
Yep, thanks to Bernat for calling this out! I’ll probably work it up tomorrow or Thursday.
I’m very excited to have this in tox!
2 Likes
Support was added to validate-pyproject 0.21 and released at 13:52 UTC, compared to tox 4.22.0 released at 18:59 UTC 
https://validate-pyproject.readthedocs.io/en/stable/changelog.html#version-0-21
6 Likes
And after adding it to the spec, please add it to the PEP using the .. canonical-pypa-spec:: directive. That will add a banner at the top of the PEP pointing people to the spec.
2 Likes
Oh wow! Looks like tox has to settle for the second position 
. Incredible work by both projects nonetheless!
2 Likes
Technically nox supported before anyone. Though just because nox is in Python so you can just load any TOML and process it yourself. 
I do think we’ll try to add dedicated helpers soon, we’ve been waiting for this PEP to design them. Support looks pretty far along in uv. Next release of pyproject-metadata will have a way to check for unsupported top-level keys, and that supports this PEP now - release likely later this week. SchemaStore shipped updated Schemas for PEP 735 a little before we released validate-pyproject 0.21, FWIW, if you want to count that.