On Oct 19, 2017, at 2:28 PM, Paul Moore <p.f.moore@gmail.com> wrote:

While I agree with this, one thing I have noticed with recent work is
that standardising existing things has typically been relatively
painless and stress-free. But designing new mechanisms generally ends
up with huge threads, heated debates, and people burning out on the
whole thing. We've had a couple of cases of that recently, and in
particular Thomas has endured the big PEP 517 debate, so I'm inclined
to say we should take a rest from new designs for a while, and keep
the scope here limited.

So I’m generally fine with keeping the scope limited, but for the same reason as I think the real solution is what I defined above, I think this isn’t/shouldn’t be a packaging standard and is a setuptools feature and should be documented/live there. If setuptools wants to enable people to directly manipulate those files they can document the standard of those files, if they want to treat it as internal and you’re expected to use their APIs then they can.

Essentially, I don’t think that a plugin system should be within the domain of distutils-sig or the PyPA and the only reason we’re even thinking of it as one is because (a) historically setuptools _had_ a plugin system and (b) we lack lifecycle hooks. I’m loathe to move the documentation for a setuptools specific feature out of their documentation because I think it muddies the water further.