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

[Paul Moore]

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.