[Distutils] PEP470 installation security problems

[Donald Stufft]

> On Oct 8, 2014, at 2:55 PM, Paul Moore <p.f.moore at gmail.com> wrote:
> 
> There's a tension here in that
> PEPs have to speak in terms of "installers" and not target pip
> specifically, as it's important to us that pip competes on an equal
> footing with other installers, and we don't act as if we have a
> privileged position.

This in particular is something I feel fairly strongly about.

I do *not* want another situation where everyone has to use X blessed thing
(e.g. distutils) or they have to go to terrible lengths (monkey patching etc)
and deal with trying to work around the expectation that there would be only
one tool (ez_setup.py imports in setup.py). That's why a big focus of mine has
been on standardizing things via the PEP process and making them formats and
APIs not implementations. I want someone to be able to come along and say "I
really "hate/think I can do better than" this pip thing and they have well
documented standards and the ability to just ignore pip all together. Now I
also hope that pip is good enough that people don't want to do that, but I want
it to be entirely possible if they do.

That's why you'll see my PEPs reference what high level features an "installer"
should implement but you'll not find much detail beyond that. I do try to
include examples and to call out what behaviors are currently in play though
just so that there's some example and "prior art" sort of information in the
PEP.

pip has a privileged position amongst installers (and possible future ones!) and
we don't want that privelege to be exasperated by making all of our PEPs pip
specific. We have a further privelege in that I'm both a pip core developer and
a PyPI admin/developer so it would be fairly easy for me to add special APIs
just for pip, but again I feel strongly about pip not being special in these
situations so we restrict ourselves.

---
Donald Stufft
PGP: 7C6B 7C5D 5E2B 6356 A926 F04F 6E3C BCE9 3372 DCFA