On 18 November 2017 at 06:54, Toshio Kuratomi <a.badger(a)gmail.com> wrote:
On Thu, Nov 16, 2017 at 8:43 PM, Nick Coghlan
> 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
Ah, OK - this makes sense.
Framing it in terms of the required input file, the two most suitable
names would be:
* "pyproject.toml compatible spec files"
* "setup.py only spec files"
I'd suggest keeping the current wheel-centric macro names, though, and
just adjust the wheel building macro to accept pyproject.toml files in
addition to setup.py files.
> At a policy management level, I think it makes sense to separate
> "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.
In that case, I'd lean towards emphasising the macros in the
guidelines, and then pointing towards the macro definitions in
dist-git if folks really want to dig into the details of what the
macros actually do. However, we'd also keep the various sections that
explain how to do various lower level things correctly (like
precompiling Python files), since those providing the "Why?" of
various decisions, which simply reading the macro source files won't
Nick Coghlan | ncoghlan(a)gmail.com | Brisbane, Australia