Upon a careful review the proposal https://wiki.freebsd.org/Python/PEP-517 is for a combination of local PEP-517 compliance and global PEP-517 compliance. Local PEP-517 compliance means that individual ports are built with a PEP-517 compliant process. Global PEP-517 compliance means that the whole ports tree is converted to PEP-517 and distutils/setuptools aren't used any longer to build Python ports.

Not every Python package even supports PEP-517 yet, so global compliance is moot and out of scope. All the wiki page does is provide a blueprint for how our ports framework supports PEP-517. The only ports to be converted at the same time are those required to bootstrap the necessary tooling. Other individual packages will roll at their own pace, independent of the framework.

One difference from the https://reviews.freebsd.org/D36061 proposal is that USE_PYTHON=build is used instead of USE_PYTHON=pep517. "build" is user's intent and is also a very easy to remember word, compared to "pep517" that isn't as easy to remember.

Again, USE_PYTHON=build is misleading. USE_PYTHON=distutils was and continues to be named as such despite actually using the setuptools package because distutils was a de facto but "largely undocumented and unmaintained collection of utilities (that) defines a configuration format that describes a Python distribution and provides the tools to convert a directory of source code into a source distribution, and some forms of binary distribution." It was also not called something like USE_PYTHON=setup, since the file can be named other than setup.py. For PEP-517, this is an actual standard that does not dictate any specific combination of tooling, but rather "toward an ecosystem of tools and tool-agnostic interoperability standards." Until relatively (as of this typing) recently, the installer and build packages did not exist (pip was first to implement PEP-517 support, but that's pip), and when they did come into existence, were not in a usable enough state for operating system-level package management to use. Besides, future-proofing the ports framework also has to consider the possibilities that installer and build may fall out of vogue or even the ports framework itself can handle virtual environment-type deployments. Additionally, the rest of the Python community have adopted the PEP-517 phrasing.

The second difference is that USE_PYTHON=build doesn't support the autoplist feature. The involved tools (build/installer) don't support autoplist and it would be unnatural and not in line with the rest of the ports tree to have autoplist just for Python ports.

autoplist is fully supported by way of the RECORD file. Just need to strip the additional CSV columns and clean up the prefixes. Those ports that do not spit out a RECORD file (it is optional) or generate an inaccurate one obviously should not use autoplist.

Python any opinions?

In D36290#851418, @fluffy wrote:

BTW, can we follow OpenBSD and hook flit too as pep517 option?

Not a good idea, since the whole point of this standard is not to recommend any particular build backend over any others, including those yet to exist, in the ecosystem. Build backends are to be specified as any other BUILD_DEPENDS.

Further testing still needed on parsing RECORD for autoplist when it comes to packages installing/listing files outside site-packages.

I'm very happy to see some action here :)

@yuri do these changes meet the requirements you have too?