<div dir="auto">I'm still not convinced, but this PEP has been WIP for too long. I think it should be marked Accepted.</div><div class="gmail_extra"><br><div class="gmail_quote">On Aug 17, 2017 9:51 PM, "Nick Coghlan" <<a href="mailto:ncoghlan@gmail.com">ncoghlan@gmail.com</a>> wrote:<br type="attribution"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">On 18 August 2017 at 02:05, 12345 67890 <<a href="mailto:xoviat@gmail.com">xoviat@gmail.com</a>> wrote:<br>
> After reviewing the PEP, I personally feel that it relies too much on the<br>
> backend Doing The Right Thing. As it currently stands, it is my<br>
> understanding that the build backend is called in the source directory and<br>
> is then responsible for handling the entire process to build a compliant<br>
> wheel. In a PEP 517 world, the build backends may be poorly written<br>
> initially and may not fully comply with the PEP’s goal to produce the same<br>
> wheel that would be produced from an sdist.<br>
><br>
> Current process:<br>
><br>
> Frontend calls backend in source directory build-wheel<br>
<br>
The PEP *allows* this, but it doesn't *require* it.<br>
<br>
> Proposed process:<br>
><br>
> Frontend copies source tree to temporary directory<br>
> Frontend invokes build-sdist to build an sdist<br>
> Frontend extracts sdist to new temporary directory<br>
> Frontend reloads backend from sdist directory and invokes build-wheel<br>
<br>
A particularly paranoid front-end remains free to work this way if it wants to.<br>
<br>
>From the PEP's point of view, it's just four distinct operations:<br>
<br>
Step 0: make a copy of the original source tree<br>
Step 1: build an sdist from the copied source tree<br>
Step 2: unpack the sdist<br>
Step 3: build a wheel from the unpacked sdist<br>
<br>
> The proposed process is more computationally intensive, but moves compliance<br>
> logic out of the build backend. In addition, we can make some modifications<br>
> based on this proposed process:<br>
><br>
> * Remove parameter for build_dir in build_wheel since it is always the current<br>
> directory<br>
<br>
We've had that discussion - build_dir models something different from<br>
what you propose (specifically, it's designed to invoke the backend's<br>
native out-of-tree build support, when that's what the frontend<br>
actually wants to invoke. If a frontend doesn't want that, don't use<br>
the setting)<br>
<br>
> Optimization: add new parameter to build_sdist called copy_extra, that when<br>
> set to false, only includes files in sdist needed to build a  wheel.<br>
<br>
No, this is the operation we decided makes no sense (and hence removed<br>
from the latest iteration of the PEP), because no build system we<br>
could find actually provides it natively.<br>
<br>
That means it would necessarily be a Python-specific capability<br>
anyway, and that further means that any backend which could be trusted<br>
to implement this feature correctly can instead be trusted to<br>
implement building an sdist or wheel directly from a source tree<br>
correctly.<br>
<br>
It's also not a major concern if early backend iterations *don't* do<br>
things correctly - those errors will be reported as bugs, fixed<br>
versions of the backends will be released, and future builds will<br>
start doing the right thing.<br>
<br>
> Specify that build_wheel should fail if PKG-INFO is not present so that it<br>
> is always invoked in an sdist<br>
<br>
No, we don't want to make that a mandatory requirement, since<br>
frontends are already free to enforce that rule if they want to (by<br>
checking for PKG-INFO before they call build_wheel), and particular<br>
backends are also free to enforce it for the packages they manage (by<br>
raising NotImplemented when they don't find PKG-INFO).<br>
<br>
Cheers,<br>
Nick.<br>
<br>
--<br>
Nick Coghlan   |   <a href="mailto:ncoghlan@gmail.com">ncoghlan@gmail.com</a>   |   Brisbane, Australia<br>
</blockquote></div></div>