Fair point 
No-one has objected to me being PEP delegate, so Iām going to assume itās down to me. Iāll review the final version of the PEP one last time and confirm my decision in the next couple of days.
4 Likes
Iāve done an other review.
Build back-ends MUST raise an error if the metadata specifies a field in dynamic but is still unspecified in the final artifact (i.e. the build back-end was unable to provide the data for a field listed in dynamic).
Iām not sure how this deals with a dynamic field ending up empty (like Requires) meaning that the field doesnāt appear in the final artifact.
How to Teach This
This section is still empty and might removed ?
Backfilling trove classifiers SHOULD occur instead of MAY happen
This section might be deleted since the related Backfilling part of the PEP has been removed ?
Require build backe-ends to update pyproject.toml when generating an sdist
back-ends
Maybe rephrase this as
Build back-ends MUST raise an error if the metadata specifies a field in dynamic but the build back-end was unable to provide the data for it.
The build backend is able to decide whether itās able to work out the correct value, so itās capable of raising this error. Thereās no need to phrase this in terms of what ends up in the metadata - the whole point of having this error is that the backend guarantees that the final metadata is reliable.
@brettcannon can you make this change (or something similar), and fix the other points @xafer raised? These are the only outstanding issues with the PEP that I can see, so Iāll make my decision on the assumption that they get addressed.
1 Like
I think @ofek is the only one of us who has actually implemented PEP 621 at this point. I would be interested to hear his taken on the final version.
I also think it might make sense to do another Provisional acceptance (or whatever PEP 517 is), but on a shorter time period, so that we can see if there are any points of friction that need clarification or adjustment as we try and implement this (particularly in setuptools, which is always the biggest PITA).
2 Likes
Iād be happy to hear comments from @ofek (or from anyone else) but at this point the PEP has been pretty much stable for 2 weeks (since @brettcannon updated it reflecting the poll results) so Iām assuming if anyone has anything more to say, theyāve had plenty of time to say it. So Iām not going to wait indefinitely ājust in caseā. To be honest, I think by this point @brettcannon deserves a decision.
Iāll post my decision at the weekend. If anyone wants to add anything further, they have until then. But it would have to be something pretty significant at this point to make much difference.
The details are here. Iām not convinced itās needed - Iād rather handle any changes using the handling fixes and minor updates process. I donāt really want to give the impression that subsequent withdrawal or rejection is possible (which provisional status allows) or that weāre expecting to make backward incompatible changes, as that will put people off adopting the format.
If we did make it a provisional acceptance, itās until āsuccessful rollout and initial adoption of the reference implementationā. Arguably, thatās already happened if @ofek has implemented it If youāre suggesting the relevant rollout should be setuptools, do you have any view on how long itāll take for that to happen? I donāt want to leave things provisional for an indefinite periodā¦
I will consider the option, though.
(As a side note, I think PEP 517 is long overdue to be moved to āFinalā status. Itās not obvious to me whether I can do that or if it needs the original BDFL-delegate - so Iāll prepare a PR to make the change and ask @ncoghlan to approve it).
Originally this PEP said that tools SHOULD backfill appropriate trove classifiers. This was changed to say it MAY occur to emphasize it was entirely optional for build back-ends to implement.
Now itās verboten so that wording should be changed.
Otherwise, it looks excellent!
Development on v1 beta of Hatch is progressing, albeit slower than I anticipated because Iām trying to implement everything on my personal backlog (except dependency locking). However, you can try it out now (docs site will come):
[build-system]
requires = ['hatchling']
build-backend = 'hatch.core.build'
[project]
name = 'foobar'
dynamic = ['version']
[tool.hatch.version]
source = 'regex'
path = 'foobar/__init__.py'
# You can override what to include with `packages`, `include`, or `exclude`,
# which all use Git-style pattern matching and can be either lists of strings
# or comma-separated strings.
#
# `packages` is like `include` but is a bit special in that it forces matching
# at the root AND the distributed path will start at the last path component
# (making it easy for src layouts, etc.).
#
# By default it will include everything not excluded by VCS
# [tool.hatch.build.targets.sdist]
# packages = ['foobar', 'tests']
# include = ['LICENSE', 'README.md']
#
# By default it will be smart about what to include
# [tool.hatch.build.targets.wheel]
# packages = ['src/foobar'] # for example
I split the project in 2: hatchling is the build back-end and hatch is still the main CLI (no code pushed yet)
2 Likes
Yep, as soon as I find the time.
1 Like
Got a PR up at https://github.com/python/peps/pull/1714. Just waiting for the status checks to pass to merge it.
1 Like
It is with pleasure that I am formally accepting PEP 621. Thanks to @brettcannon and the other authors for their work in developing the PEP, and to the ācast of thousandsā who contributed to the discussions.
After reflection, I have decided that the PEP is initially accepted as provisional, to allow time for any issues identified as tools implement the spec to be ironed out. But I am strictly limiting the provisional status to a maximum of (just over) three months, so the PEP will be declared final on 1st March 2021. If we have fully working implementations of the PEP sooner than that, Iām happy to move the status to final before the deadline.
13 Likes
PEP 1 doesnāt spell it out, but I agree it makes sense for the BDFL-Delegate to approve leaving the Provisional state (reverting to the SC if the original delegate is uncontactable).
And for this specific case, I agree that the Provisional qualification can now be removed - the proposal has been successfully implemented and deployed.
1 Like
Thanks! Glad the PEP worked out in the end!
Would you like me to hold off on a PR for packaging.python.org to link to the PEP from there (or fully copying it over so the official version is kept on packaging.python.org entirely)?
I donāt think thereās a need to hold off. Sure, thereās a possibility of change due to the provisional status, but I certainly donāt think we should delay having official documentation until the provisional status is removed.
Iād prefer it if the official version were kept on packaging.python.org, rather than just linking to the PEP, but that is a non-trivial amount of extra work, so Iām perfectly fine if you prefer to just link to the PEP for now.
2 Likes
Iām happy to put in the work to move it all over to packaging.python.org since it will make it easier to read due to having less comparison details to other tools and such.
1 Like
Quick update: I marked the PEP as provisionally accepted. Next step is creating the page for the spec on packaging.python.org.
1 Like
PR for the spec on packaging.python.org: https://github.com/pypa/packaging.python.org/pull/797.
1 Like
As an update to this, PEP 621 is now officially declared as Final. @brettcannon can you update the PEP to reflect this?
2 Likes
PEP 621: mark as final by brettcannon Ā· Pull Request #1857 Ā· python/peps Ā· GitHub has the update to final.
3 Likes
Iāve just released Flit 3.2 with experimental support for PEP 621. Itās also using PEP 621 itself (is it the first package to do so? 
)
This is largely undocumented for now - the idea is that early adopters can try it out before everyone switches over. Iām asking that anyone who does try it out declare that only Flit 3.2.x should build their project, in case the support needs to change for 3.3 - i.e. start pyproject.toml like this:
[build-system]
requires = ["flit_core >=3.2.0,<3.3"]
6 Likes
I released whey (as in curds and whey, used to make wheels of cheese; Home - whey 0.0.6 documentation), a PEP 517 backend with PEP 621 support, on the 23rd Feb. Iāve used it for several of my projects already.
Iām curious how flit handles the case where one author has only a name and one has only an email like in the example? It wasnāt obvious to me what should go in which core metadata field.
1 Like