> 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@gmail.com>:
On 19 August 2017 at 21:30, xoviat <xoviat@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