On 17 November 2017 at 11:55, Toshio Kuratomi <a.bad...@gmail.com> wrote: > > On Thu, Nov 16, 2017 at 5:37 PM, Nick Coghlan <ncogh...@gmail.com> wrote: > > 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) > > > > I'm not sure what you're saying. I must be further outside of the > packaging loop than I thought. > > The two questions that I need to know the answer to to make sure we're > even vaguley on the same page are: > > * Is the rpm Source: line still going to be an sdist? > * Are the files that are in the built rpm going to be the same as now?
Yes, those are both unchanged. The issue is specifically with the example in https://fedoraproject.org/wiki/Packaging:Python#Example_common_spec_file, which only shows the %pyX_build and %pyX_install macros, which assume that the right way to install a Python project inside the buildroot is to run: "setup.py build" in the %build step "setup.py install" in the %install step That works as long as the project either uses setup.py natively (i.e. distutils/setuptools projects), or provides a backwards compatibility shim, but won't work consistently for newer projects that rely on pyproject.toml and the static build dependency declarations from PEPs 517 & 518. Switching to a wheel based build doesn't change either the starting point (which is still an sdist) or the end point (which is still a policy compliant RPM), it changes the internal interface between the build step and the install step from being a distutils build directory to a wheel archive: "pip wheel" (or "setup.py bdist_wheel") in the %build step "pip install" in the %install step At a policy management level, I think it makes sense to separate the "these are the policy decisions you *must* abide by" guidelines (which are the domain of FPC) from the "Here are the helper macros that we provide to make it easier to abide by those guidelines". The distinction is that you can still pass a package review without using the helper macros, but you'll still want to use them in most cases simply because they make ongoing package maintenance easier (since the helper macros will adjust automatically to rebases and policy changes, while handcrafted spec files might not). Cheers, Nick. -- Nick Coghlan | ncogh...@gmail.com | Brisbane, Australia _______________________________________________ python-devel mailing list -- python-devel@lists.fedoraproject.org To unsubscribe send an email to python-devel-le...@lists.fedoraproject.org
