[Distutils] Finishing up PEP 517

[Nathaniel Smith]

On Tue, Jun 27, 2017 at 9:29 PM, Nick Coghlan <ncoghlan at gmail.com> wrote:
> Sorry, I also meant to reply to this part before hitting send.
>
> On 28 June 2017 at 13:43, Nathaniel Smith <njs at pobox.com> wrote:
>> I would say that there's only one required path, which is in-place.
>> (But the tree that they do the in-place build in might have a more or
>> less complicated history). It worries me that you seem to think that
>> build_sdist and build_wheel should be coupled like this... this
>> proliferation of cases and the reification of "out of tree builds" as
>> a special thing that's different from an in-tree build in a temporary
>> tree is already what worried me about prepare_wheel_input_files, and
>> now it seems to be spreading :-).
>
> I don't know what additional coupling you're seeing: the only coupling
> is that building a wheel directly from a VCS source tree and first
> exporting an sdist and then building a wheel from that *must give the
> same result* (modulo any problems related to reproducible builds, or
> the lack thereof). If a project can't meet that expectation, then
> their sdist generation is broken, since it clearly isn't exporting the
> necessary content to actually build the project properly.
>
> If you weren't aware of that inherent coupling, and are surprised by
> the fact that it's a constraint on publishing useful sdists, then I'd
> consider it a good thing that PEP 517 is now making it more explicit.

What I'm concerned about is that in your formulation, you're running
different code to build a wheel from an sdist that we just generated,
versus an sdist that we downloaded from PyPI. By making it possible to
distinguish these cases, you're facilitating projects that break that
inherent coupling (either accidentally or on purpose).

I think that in these two cases, all the hooks used in the
wheel-building phase should be run in exactly the same way, i.e.,
inside the unpacked sdist, with no reference to the original working
tree that that sdist was generated from. Since the PyPI case can't
access the original working tree, the local out-of-place-build case
generate the sdist and then after that pretend it can't access the
original working tree either.

-n

-- 
Nathaniel J. Smith -- https://vorpus.org