[RFC] Support for PEP517 build systems with new build style

[ahesford]

I have been told that PEP517 build systems are the way of the future for Python package building and installation, and setuptools will become (or is now) disfavored. python3-packaging is the first of our packages to drop setuptools and specifically require a PEP517 builder.

This is an attempt to support PEP517 builds in our python3-module build style. For now, the preferred (only?) way to do PEP517 builds is to rely on pip to do the work. Fortunately, because no PEP517 builder supports compiled extensions, we can avoid the pain of trying to force pip to behave with cross compilers (for now).

Use of the PEP517 build procedure in a template is enabled by setting python_pep517=yes. If this is adopted, we'll have to modify xlint as well.

pip can do a one-pass build and install, but I figured it was better to split into a build-wheel stage and an install-wheel stage so people can do ./xbps-src build and investigate the artifacts.

I am not thrilled with the use of globs in do_install when setting a default $python_pep517_wheel but, according to PEP 427 and its referenced PEP 425, the filename components I'm trying to match with the globs are not easily predicted. In any case, if this produces undesirable behavior in specific templates, the author can manually set that variable. Any other ideas are welcome.

Finally, the build process produces direct_url.json in the Python dist-info directory to comply with PEP 610, which replaces a simple version number in pip freeze output with a file:// URL pointing to the location of the wheel used for installation. (In our case, this will be /builddir/$wrksrc/$build_wrksrc/$python_pep517_wheel.) For distribution packages, I do not believe this is desirable. We can manually remove the file, for example in do_install, assuming the dist-info directory is predictable. Comments about doing this are welcome.

cc: any @void-linux/pkg-committers with a stake in Python packages

[ericonr]

We could try adding the pytest option to do_check, what do you think?

if command -v pytest >/dev/null; then \n pytest

[ahesford]

Not a bad idea, but I've gone one step further. Running python setup.py test complains about deprectation and suggests tox instead. Because that is the official recommendation, I try tox first if possible, otherwise try pytest if possible, and finally fall back to the old behavior for non-PEP517 builds.

I've modified a few templates as an example of how the change eliminates some redundancy.

If there is not significant debate about the PEP517 changes, I'll squash the two build-style/python3-module commits before merging. For now, I'll keep them apart so we can separate the two issues if need be.

[ericonr]

See #25052 for some discussion about tox.

Btw, this PR closes that issue.

[ahesford]

Based on opposition in the mentioned issue, I dropped tox from the build style and kept the preference for pytest over the deprecated setup.py test method.

[ericonr]

Remember to add to the Manual, as well :)

[Johnnynator]

Why not do it as a seperate build_style? I would see it as a totally different build system and therefore it also should be in it's own build_style, especially since it already doesn't do it automatically but you need to manually set a var.

[ahesford]

On 2020-12-02 at 14:43 (UTC -0500), John Zimmermann wrote: Why not do it as a seperate build_style? I would see it as a totally different build system and therefore it also should be in it's own build_style, especially since it already doesn't do it automatically but you need to manually set a var.

I don't oppose splitting this into a separate build style. Are there arguments against doing so? If it does become its own style, any thoughts on the name? An obvious choice is `python3-pep517`, but we could also go for something like `python3-wheel` if "pep517" seems like inside baseball.

[fosslinux]

I agree with @Johnnynator

[ahesford]

Comment added to update restriction on python-packaging, created a separate python3-pep517 build style and updated the manual. This simplified some things, and I moved the pytest adoption in python3-module to #26901 for separate consideration.

While doing a separate build style, I decided to allow $make_build_target to override the default $PWD target when necessary, and uesd $make_install_target instead of a new variable to select the wheel used for installation. This avoids the need for an xlint update.

[Chocimier]

make_*_target needs documentation, as they are used a bit different than in make-based build styles.
Add new build style to build style scripts section too.
Please do not reformat existing manual sections when they stay with same content. Minimal, meaningful diffs are good.

[ahesford]

I added the make_*_target behaviors to #optional_vars, added the new style to #build_scripts and cleaned up the diff in #pkgs_python.

[Chocimier]

Few more packages declaring build-backend builds with that, few fail, but that's not our fault.

Lgtm.

[ahesford]

Closed in fe9c2d0.