[Distutils] PEP 517: Build frontend responsibilities

xoviat xoviat at gmail.com
Sat Aug 19 17:00:07 EDT 2017


> The setuptools and pip master branches are for things which *are*
expected to go into the next version, not for experimental changes

I agree with that statement (the PRs as they currently are need work
because they have become stale) in the sense that code in the master branch
should work at all times. But that's different than the PEP being fully
fleshed out for all build systems rather than just pip and setuptools. And
also, a big reason for this is that to be frank, the first implementation
will probably not work. That's not just some special rule that I have
applied to myself, but it's also the reality with PEP 518. The reality is
that PEP 518 does not currently work and it is in the master branch, but
people did not discover that fact until it was in the master branch. You
can't know what you can't know.

If an implementation that does not comply with the PEP yet but works with
appropriate fallbacks to verify setuptools support and compliance, then
it's not the end of the world if the packages are still built and installed
correctly.

2017-08-19 16:48 GMT-04:00 Paul Moore <p.f.moore at gmail.com>:

> On 19 August 2017 at 21:30, xoviat <xoviat at gmail.com> wrote:
> > Also, I disagree with this point. I think it's still possible (and in
> fact
> > preferable) to have setuptools and pip 'test this out' with appropriate
> > fallbacks before opening this up to the wider community. Most people
> > wouldn't even notice because they wouldn't be using HEAD.
>
> The same people who would notice it are probably just as able to apply
> a patch/PR or grab a fork. So your PRs are available for people to
> test if they want to, they don't need to be merged for that to happen.
>
> The setuptools and pip master branches are for things which *are*
> expected to go into the next version, not for experimental changes
> (for pip, we should be able to release from master whenever we want
> to, I suspect setuptools has a similar policy).
>
> Paul
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/distutils-sig/attachments/20170819/f754fa39/attachment.html>


More information about the Distutils-SIG mailing list