> On Feb 16, 2016, at 4:33 PM, Noah Kantrowitz <n...@coderanger.net
> <mailto:n...@coderanger.net>> wrote:
>
>
>> On Feb 16, 2016, at 4:27 PM, Glyph Lefkowitz <gl...@twistedmatrix.com
>> <mailto:gl...@twistedmatrix.com>> wrote:
>>
>>
>>> On Feb 16, 2016, at 4:13 PM, Noah Kantrowitz <n...@coderanger.net
>>> <mailto:n...@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
_______________________________________________
Distutils-SIG maillist - Distutils-SIG@python.org
https://mail.python.org/mailman/listinfo/distutils-sig
