On 17 November 2017 at 01:51, Toshio Kuratomi <a.badger@gmail.com> wrote:

On Nov 16, 2017 4:59 AM, "Nick Coghlan" <ncoghlan@gmail.com> wrote:

Rather than emphasising the absence of setup.py, I'd emphasise the use of wheel files:

* "Defining an RPM based on a wheel build process"
* "Defining an RPM based on a setup.py file"

I would not emphasize the use of wheel files as they are not source and from flit's documentation, it doesn't appear that wheels are even central to it (contrast how much wheel is mentioned in its documentation compared to pyproject.tom). Instead I would emphasize flit itself as the build tool which we're using to transform the source into the files on our systems. If there's ever an alternative to flit which builds with wheels as part of that process we'll need new guidelines based on that so using wheel as the prime keyword that people associate with this build process instead of flit is not future proof either.

It's not just flit - it's enscons and other PEP 517/518 backends, whereby the only thing we know for sure about the sdist in the long term is that "pip wheel" (and other PEP 517 frontends) will be able to convert it into a Python wheel in the %build phase, which can then be unpacked by the wheel installation macro in the %install phase.

So the two possible approaches are:

* traditional sdist: "setup.py build", "setup.py install"

* Current wheel macros: "setup.py bdist_wheel", "pip install <wheel file>"

If we tweak the %py_build_wheel macro to use `pip wheel` [1] rather than calling `setup.py bdist_wheel` directly, then even the wheel build macro would be usable without a setup.py shim (once pip itself fully supports PEP 517/518)

Cheers,

Nick.

[1] https://pip.pypa.io/en/stable/reference/pip_wheel/

Nick Coghlan | ncoghlan@gmail.com | Brisbane, Australia