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

[Glyph Lefkowitz]

> On Feb 16, 2016, at 4:33 PM, Noah Kantrowitz <noah at coderanger.net <mailto:noah at coderanger.net>> wrote:
> 
> 
>> On Feb 16, 2016, at 4:27 PM, Glyph Lefkowitz <glyph at twistedmatrix.com <mailto:glyph at twistedmatrix.com>> wrote:
>> 
>> 
>>> On Feb 16, 2016, at 4:13 PM, Noah Kantrowitz <noah at coderanger.net <mailto: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 <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/

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.

> 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).

-glyph
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/distutils-sig/attachments/20160216/55be57b1/attachment.html>