> On Oct 19, 2017, at 2:28 PM, Paul Moore <p.f.mo...@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.
_______________________________________________
Distutils-SIG maillist - Distutils-SIG@python.org
https://mail.python.org/mailman/listinfo/distutils-sig
