> On Feb 17, 2016, at 7:17 PM, Nathaniel Smith <n...@pobox.com> wrote: > > On Tue, Feb 16, 2016 at 6:12 PM, Glyph Lefkowitz > <gl...@twistedmatrix.com> wrote: >> Here, I'll make it for you. Assuming virtualenv is installed: >> >> python -m virtualenv /usr/lib/supervisord/environment >> /usr/lib/supervisord/environment/bin/pip install supervisord >> ln -vs /usr/lib/supervisord/environment/bin/supervisor* /usr/bin >> >> >> More tooling around this idiom would of course be nifty, but this is really >> all it takes. > > Maybe > > pip install --self-contained=/opt/supervisord supervisord > > should do something like this?
I think making pip do this might be mixing layers too much. Frankly `pipsi´ does almost the right thing; if `sudo pipsi´ put script symlinks in /usr/local/bin/ instead of ~/.local/bin/ and put venvs into /usr/local/lib/pipsi/<envname>/ instead of ~/.local/venvs/<envname>, it would be almost exactly the right thing. (I previously said "/usr/bin/" but the whole point of /usr/local is that it's a place you can write to which _is_ on the default path but _isn't_ managed by the system package manager.) Whatever the invocation is though, Noah has a point about system administrator expectations. If you always have to manually specify a path for --self-contained, then there's going to be no standard place to go look to see what applications are installed via this mechanism, and it makes diagnostics harder. There could of course be an option to put the install somewhere else, but if it's going to be pip, then it should be: pip install --self-contained supervisor by default, and pip install --self-contained --self-contained-environment=/opt/supervisor supervisor in the case where the user wants a non-standard location. -glyph
_______________________________________________ Distutils-SIG maillist - Distutils-SIG@python.org https://mail.python.org/mailman/listinfo/distutils-sig
