On Thu, Nov 16, 2017 at 8:43 PM, Nick Coghlan <ncogh...@gmail.com> wrote: > 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 > So This seems more like "Building packages via pip" or "Building packages that use pyproject.toml". wheels are actually an implementation detail here that doesn't really surface to the either the input side or the output side. we don't care if the build tool (pip in this example) takes the sdist with a pyproject.toml file and builds a wheel, a _build/ directory, or some other intermediate format. We just care that it builds the appropriate files in this step and then installs from that built resource in the second step. This is why the name and focus seems wrong to me. the importance to us when building from source is the metadata format and the tools that transform the source code with that metadata into a built resource on our filesystem.
> 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). > So, How to write a package that complies with the guidelines is also the domain of the FPC (at least, right now). So you need to have something inside of the guidelines that shows how to use these things. I leaned towards spelling out the manual steps and then showing that there were macros that encapsulated some of those steps but that may no longer be the preferred direction. The guidelines must have at least one or the other, though. This doesn't conflict with your last statement (whether the package does or does not have to use the macros) but it does conflict with the implicit idea that the FPC is limited to the policy decisions that you must abide by and also is a problem when you talk about not having any in-guidelines information on how to build the packages that have pyproject.toml. -Toshio _______________________________________________ python-devel mailing list -- python-devel@lists.fedoraproject.org To unsubscribe send an email to python-devel-le...@lists.fedoraproject.org
