[Distutils] Don't Use `sudo pip install´ (was Re: [final version?] PEP 513…)

[Noah Kantrowitz]

> On Feb 16, 2016, at 4:46 PM, Glyph Lefkowitz <glyph at twistedmatrix.com> wrote:
> 
>> 
>> On Feb 16, 2016, at 4:33 PM, Noah Kantrowitz <noah at coderanger.net> wrote:
>> 
>> 
>>> On Feb 16, 2016, at 4:27 PM, Glyph Lefkowitz <glyph at twistedmatrix.com> wrote:
>>> 
>>> 
>>>> On Feb 16, 2016, at 4:13 PM, Noah Kantrowitz <noah at coderanger.net> wrote:
>>>> 
>>>> As someone that handles the tooling side, I don't care how it works as long as there is an override for tooling a la Chef/Puppet. For stuff like Supervisord, it is usually the least broken path to install the code globally.
>>> 
>>> I don't know if this is the right venue for this discussion, but I do think it would be super valuable to hash this out for good.
>>> 
>>> Why does supervisord need to be installed in the global Python environment?
>> 
>> Where else would it go? I wouldn't want to assume virtualenv is installed unless absolutely needed.
> 
> This I can understand, but: in this case, it is needed ;).
> 
>> Virtualenv is a project-centric view of the world which breaks down for stuff that is actually global like system command line tools.
> 
> [citation needed].  In what way does it "break down"?  https://pypi.python.org/pypi/pipsi is a nice proof-of-concept that dedicated virtualenvs are a better model for tooling than a big-ball-of-mud integrated system environment that may have multiple conflicting requirements.  Unfortunately it doesn't directly address this use-case because it assumes that it is doing per-user installations and not a system-global one, but the same principle holds: what version of `ipaddress´ that supervisord wants to use is irrelevant to the tools that came with your operating system, and similarly irrelevant to your application.
> 
> To be clear, what I'm proposing here is not "shove supervisord into a venv with the rest of your application", but rather, "each application should have its own venv".  In supervisord's case, "python" is an implementation detail, and therefore the public interface is /usr/bin/supervisord and /usr/bin/supervisorctl, not 'import supervisord'; those should just be symlinks into /usr/lib/supervisord/environment/bin/

That isn't a thing that exists currently, I would have to make it myself and I wouldn't expect users to assume that is how I made it work. Given the various flavors of user expectations and standards that exist for deploying Python code, global does the least harm right now.

> In fact, given that it is security-sensitive code that runs as root, it is extra important to isolate supervisord from your system environment for defense in depth, so that, for example, if, due to a bug, it can be coerced into importing an arbitrarily-named module, it has a restricted set and won't just load anything off the system.

Sounds cute but the threats that actually helps with seem really minor. If a user can install stuff as root, they can probably do whatever they want thanks to .pth files and other terrible things.

>> Compare with `npm install -g grunt-cli`.
> 
> npm is different because npm doesn't create top-level script binaries unless you pass the -g option, so you need to install global tooling stuff with -g.  virtualenv is different (and, at least in this case, better).

Pip also doesn't generate binstubs in /usr/bin unless you install globally so pretty much same difference.

--Noah

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 163 bytes
Desc: Message signed with OpenPGP using GPGMail
URL: <http://mail.python.org/pipermail/distutils-sig/attachments/20160216/ab82734f/attachment.sig>