[Distutils] A possible refactor/streamlining of PEP 517

[Nick Coghlan]

On 11 July 2017 at 06:56, Paul Moore <p.f.moore at gmail.com> wrote:
> On 10 July 2017 at 21:28, Thomas Kluyver <thomas at kluyver.me.uk> wrote:
>> I don't think it's practical to forbid generating files to put in the
>> sdist, but for pep517 I'd say it's appropriate to gently discourage it
>> by not providing a build directory to that hook. I'm not going to argue
>> hard for this if other people think the sdist hook needs that parameter,
>> though.
>
> I also don't think it's a huge issue either way (and it's definitely a
> tangential issue as far as PEP 517 is concerned) but anecdotally I
> have encountered packages that have taken a substantial amount of time
> (30 minutes+) to run Cython on the sources[1]. Having pregenerated C
> files in the sdist made the difference between "usable" and "not worth
> bothering" in that case.

Right, I realised through this discussion that my previous mental
mapping of "sdist->SRPM, wheel->RPM" isn't actually *quite* right,
since the objectives of the Python level packaging ecosystem and a
redistributor-centric system like RPM aren't exactly the same.

In particular, I now realise that if a redistributor wants to
absolutely *ensure* that we have the source in the preferred form for
modification, then we technically need to be starting with the VCS
commit or release tarball rather than the sdist, and it's just an
artifact of history that those two starting points have traditionally
been roughly equivalent.

This is due to the fact that it makes sense for publishers to optimise
their sdists and wheels to provide the best possible experience for
folks using the *Python* level tooling, whereby:

- sdists are nominally architecture, platform and Python version
independent source archives for common compile toolchains
- wheels are pre-built archives for common Python versions, platforms
and architectures

So while I still suggest we omit "build_directory" from the
build_sdist signature (at least for the initial iteration of the API
design), I'm now only -0 on the idea, rather than my original -1.

Cheers,
Nick.

-- 
Nick Coghlan   |   ncoghlan at gmail.com   |   Brisbane, Australia