[Distutils] Provisionally accepting PEP 517's declarative build system interface

Paul Moore p.f.moore at gmail.com
Sat Jun 3 05:12:41 EDT 2017

On 3 June 2017 at 09:59, Paul Moore <p.f.moore at gmail.com> wrote:
> On 3 June 2017 at 03:14, Nathaniel Smith <njs at pobox.com> wrote:
>> So far my belief is that packages with expensive build processes are
>> going to ignore you and implement, ship, document, and recommend the
>> direct source-tree->wheel path for developer builds. You can force the
>> make-a-wheel-from-a-directory-without-copying-and-then-install-it
>> command have a name that doesn't start with "pip", but it's still
>> going to exist and be used. Why wouldn't it? It's trivial to implement
>> and it works, and I haven't heard any alternative proposals that have
>> either of those properties. [1]
> I may be misunderstanding you, but it's deeply concerning if you're
> saying "as a potential backend developer, I'm sitting here listening
> to the discussion about PEP 517 and I've decided not to raise my
> concerns but simply to let it be implemented and then ignore it".
> OTOH, I'm not sure how you plan on ignoring it - are you suggesting
> that projects like numpy won't support "pip install numpy" except for
> wheel installs[1]?
>> One thing that's not clear to me: a crucial use case for sdists is (1)
>> download, (2) unpack, (3) patch the source, possibly adding new files,
>> (4) build and install. (After all, the whole reason we insist on
>> distributing sdists is that open source software should be modifiable
>> by the recipient.) Does flit currently support this, given the
>> reliance on VCS metadata?
> That's a reasonable concern, and a reservation I have about flit's
> sdist support, but as a comment about flit, it probably belongs more
> on the flit tracker than here.
> As a point for PEP 517, I think it's valid though. I'd suggest that
> the PEP add a few more lines on what constitutes a "source tree", by
> offering some examples. It seems to me that the two key examples of a
> "source tree" that the PEP must support are
> 1. A VCS checkout of a project under development.
> 2. An unpacked sdist that the user has made edits to before building.
> (The second of these being the one we're talking about here).
> Paul
> [1] By "won't support" consider that in a PEP 517 world, pip issues
> stating "pip install <numpy source checkout> takes too long" or
> similar will be passed to the backend developer with the suggestion
> that they implement the build_sdist or copy_files hook. Saying numpy
> won't support PEP 517 means that such requests will be denied.

Apologies, gmail's web interface split the conversation thread so I
wrote this before reading through to the end, so some of what I say is
out of date given subsequent emails. Bad gmail, sorry :-)


More information about the Distutils-SIG mailing list