On 17 November 2017 at 01:51, Toshio Kuratomi <a.badger(a)gmail.com> wrote:
On Nov 16, 2017 4:59 AM, "Nick Coghlan"
<ncoghlan(a)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(a)gmail.com | Brisbane, Australia