On 18 November 2017 at 06:54, Toshio Kuratomi wrote:
> On Thu, Nov 16, 2017 at 8:43 PM, Nick Coghlan wrote:
>> 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.
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 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.
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
give you.
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
