Github messages for voidlinux
 help / color / mirror / Atom feed
From: ahesford <ahesford@users.noreply.github.com>
To: ml@inbox.vuxu.org
Subject: Re: [PR PATCH] [Closed]: [RFC] Support for PEP517 build systems with new build style
Date: Tue, 08 Dec 2020 21:57:27 +0100	[thread overview]
Message-ID: <20201208205727.dP4HxsY-uOu00ipEnSBfVqDytUtSuldNDBdbgzZP8hA@z> (raw)
In-Reply-To: <gh-mailinglist-notifications-41a7ca26-5023-4802-975b-f1789d68868e-void-packages-26883@inbox.vuxu.org>

[-- Attachment #1: Type: text/plain, Size: 2382 bytes --]

There's a closed pull request on the void-packages repository

[RFC] Support for PEP517 build systems with new build style
https://github.com/void-linux/void-packages/pull/26883

Description:
I [have been told](https://github.com/pypa/packaging/issues/363) 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](https://www.python.org/dev/peps/pep-0427/#file-name-convention) and its referenced [PEP 425](https://www.python.org/dev/peps/pep-0425), 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](https://www.python.org/dev/peps/pep-0610), 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

      parent reply	other threads:[~2020-12-08 20:57 UTC|newest]

Thread overview: 23+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2020-12-02 16:00 [PR PATCH] [RFC] Support for PEP517 build systems in python3-module ahesford
2020-12-02 17:45 ` [PR REVIEW] " ericonr
2020-12-02 19:02 ` [PR PATCH] [Updated] " ahesford
2020-12-02 19:06 ` [PR REVIEW] " ahesford
2020-12-02 19:10 ` ericonr
2020-12-02 19:11 ` ericonr
2020-12-02 19:14 ` ericonr
2020-12-02 19:27 ` [PR PATCH] [Updated] " ahesford
2020-12-02 19:28 ` [PR REVIEW] " ahesford
2020-12-02 19:30 ` [PR PATCH] [Updated] " ahesford
2020-12-02 19:42 ` Johnnynator
2020-12-02 19:59 ` ahesford
2020-12-02 20:21 ` [PR REVIEW] " Chocimier
2020-12-02 23:37 ` fosslinux
2020-12-03  3:43 ` [PR PATCH] [Updated] " ahesford
2020-12-03  3:52 ` ahesford
2020-12-05 16:29 ` [RFC] Support for PEP517 build systems with new build style Chocimier
2020-12-06  5:48 ` [PR PATCH] [Updated] " ahesford
2020-12-06  5:53 ` ahesford
2020-12-06  5:56 ` ahesford
2020-12-06  5:56 ` ahesford
2020-12-08 20:57 ` ahesford
2020-12-08 20:57 ` ahesford [this message]

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20201208205727.dP4HxsY-uOu00ipEnSBfVqDytUtSuldNDBdbgzZP8hA@z \
    --to=ahesford@users.noreply.github.com \
    --cc=ml@inbox.vuxu.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).