There's a somewhat compelling use case for `pip install foo` not trusting the packages, but the actual Python code that runs "import foo" trusting it. In particular, if I'm a sysadmin of a shared machine and a user asks me to install something systemwide, I don't want arbitrary code running as root, but if the installed code is malicious, that's up to the unprivileged user who chooses to use it to keep their own data safe.
It's not terribly compelling given stuff like virtualenv, though, since users can just `pip install` stuff on their own and the experience is strictly nicer. And it's also not compelling if there isn't an explicit promise that this is treated as a security boundary.
> In particular, if I'm a sysadmin of a shared machine and a user asks me to install something systemwide, I don't want arbitrary code running as root, but if the installed code is malicious, that's up to the unprivileged user who chooses to use it to keep their own data safe.
Ah, that makes a lot of sense, especially for applications (eg meld) and command line utilities (eg httpie) which are nice to install systemwide as root, but only ever run in an unprivileged user's context.
It's not terribly compelling given stuff like virtualenv, though, since users can just `pip install` stuff on their own and the experience is strictly nicer. And it's also not compelling if there isn't an explicit promise that this is treated as a security boundary.