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