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

[Glyph Lefkowitz]

> On Feb 17, 2016, at 7:44 PM, Glyph Lefkowitz  wrote:
> 
> 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// instead of ~/.local/venvs/, it would 
> be almost exactly the right thing.

I filed an issue here - https://github.com/mitsuhiko/pipsi/issues/69 - so we 
can continue discussion of this specific solution in a more appropriate forum.

-glyph

___
Distutils-SIG maillist  -  Distutils-SIG@python.org
https://mail.python.org/mailman/listinfo/distutils-sig

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

[Glyph Lefkowitz]

> On Feb 17, 2016, at 7:17 PM, Nathaniel Smith  wrote:
> 
> On Tue, Feb 16, 2016 at 6:12 PM, Glyph Lefkowitz
>  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// instead of ~/.local/venvs/, 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

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

[Nathaniel Smith]

On Tue, Feb 16, 2016 at 6:12 PM, Glyph Lefkowitz
 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?

-n

-- 
Nathaniel J. Smith -- https://vorpus.org
___
Distutils-SIG maillist  -  Distutils-SIG@python.org
https://mail.python.org/mailman/listinfo/distutils-sig

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

[Glyph Lefkowitz]

> On Feb 17, 2016, at 7:08 PM, Noah Kantrowitz  wrote:
> 
> Saying it's a good idea and we should move towards it is fine and I agree, 
> but that isn't grounds to remove the ability to do things the current way. So 
> you can warn people off from global installs but until there is at least some 
> community awareness of this other way to do things we can't remove support 
> entirely. It's going to be a very slow deprecation process.
> 
> --Noah

Sure.  We are also in agreement here, basically: in saying that pip should 
"error", I was describing an ideal state that would take years of education to 
get to (and I'm not sure that Donald even agrees we should go that way ;-)).  
But we can't even begin to move in that direction a little unless the better 
alternative is clearly explained and out in the zeitgeist for some time first.

-glyph___
Distutils-SIG maillist  -  Distutils-SIG@python.org
https://mail.python.org/mailman/listinfo/distutils-sig

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

[Noah Kantrowitz]

> On Feb 17, 2016, at 5:58 AM, Glyph Lefkowitz  wrote:
> 
> 
>> On Feb 16, 2016, at 6:22 PM, Noah Kantrowitz  wrote:
>> 
>> I'm not concerned with if the module is importable specifically, but I am 
>> concerned with where the files will live overall. When building generic ops 
>> tooling, being unsurprising is almost always the right move and I would be 
>> surprised if supervisor installed to a custom virtualenv.
> 
> Would you not be surprised if installing supervisord upgraded e.g. `six´ or 
> `setuptools´ and broke apport? or lsb_release? or dnf?  This type of version 
> conflict is of course rare, but it is always possible, and every 'pip 
> install' takes the system from a supported / supportable state to "???" 
> depending on the dependencies of every other tool which may have been 
> installed (and pip doesn't have a constraint solver for its dependencies, so 
> you don't even know if the system gets formally broken by two explicitly 
> conflicting requirements).
> 
>> It's a weird side effect of Python not having a great solution for 
>> "application packaging" I guess? We've got standards for web-ish 
>> applications, but not much for system services. I'm not saying I think 
>> creating an isolated "global-ish" environment would be worse, I'm saying 
>> nothing does that right now and I personally don't want to be the first 
>> because that bring a lot of pain with it :-)
> 
> What makes the web-ish stuff "standard" is just that a lot of people are 
> doing it.  So a lot of people should start doing this, and then it will also 
> be a standard :-).
> 
> I can tell you that on systems where I've done this sort of thing, it has 
> surprised no-one that I'm aware of and I have not had any issues to speak of. 
>  So I think you might be overestimating the risk.
> 
> In fairness though I've never written a clear explanation anywhere of why 
> this is desirable; it strikes me as obvious but it is clearly not the present 
> best-practice, which means somebody needs to do some thought-leadering.  So I 
> owe you a blog post.

Saying it's a good idea and we should move towards it is fine and I agree, but 
that isn't grounds to remove the ability to do things the current way. So you 
can warn people off from global installs but until there is at least some 
community awareness of this other way to do things we can't remove support 
entirely. It's going to be a very slow deprecation process.

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

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

[Glyph Lefkowitz]

> On Feb 16, 2016, at 6:22 PM, Noah Kantrowitz  wrote:
> 
> I'm not concerned with if the module is importable specifically, but I am 
> concerned with where the files will live overall. When building generic ops 
> tooling, being unsurprising is almost always the right move and I would be 
> surprised if supervisor installed to a custom virtualenv.

Would you not be surprised if installing supervisord upgraded e.g. `six´ or 
`setuptools´ and broke apport? or lsb_release? or dnf?  This type of version 
conflict is of course rare, but it is always possible, and every 'pip install' 
takes the system from a supported / supportable state to "???" depending on the 
dependencies of every other tool which may have been installed (and pip doesn't 
have a constraint solver for its dependencies, so you don't even know if the 
system gets formally broken by two explicitly conflicting requirements).

> It's a weird side effect of Python not having a great solution for 
> "application packaging" I guess? We've got standards for web-ish 
> applications, but not much for system services. I'm not saying I think 
> creating an isolated "global-ish" environment would be worse, I'm saying 
> nothing does that right now and I personally don't want to be the first 
> because that bring a lot of pain with it :-)

What makes the web-ish stuff "standard" is just that a lot of people are doing 
it.  So a lot of people should start doing this, and then it will also be a 
standard :-).

I can tell you that on systems where I've done this sort of thing, it has 
surprised no-one that I'm aware of and I have not had any issues to speak of.  
So I think you might be overestimating the risk.

In fairness though I've never written a clear explanation anywhere of why this 
is desirable; it strikes me as obvious but it is clearly not the present 
best-practice, which means somebody needs to do some thought-leadering.  So I 
owe you a blog post.

-glyph

___
Distutils-SIG maillist  -  Distutils-SIG@python.org
https://mail.python.org/mailman/listinfo/distutils-sig

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

[Noah Kantrowitz]

> On Feb 16, 2016, at 6:12 PM, Glyph Lefkowitz  wrote:
> 
>> 
>> On Feb 16, 2016, at 5:00 PM, Noah Kantrowitz  wrote:
>> 
>> 
>>> On Feb 16, 2016, at 4:46 PM, Glyph Lefkowitz  
>>> wrote:
>>> 
 
 On Feb 16, 2016, at 4:33 PM, Noah Kantrowitz  wrote:
 
 
> On Feb 16, 2016, at 4:27 PM, Glyph Lefkowitz  
> wrote:
> 
> 
>> On Feb 16, 2016, at 4:13 PM, Noah Kantrowitz  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.
> 
> I don't think users who install supervisord necessarily think they ought to 
> be able to import supervisord.  If they do expect that, they should probably 
> revise their expectations.
> 
> 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.
> 
>>> 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.
> 
> Once malicious code is installed in a root-executable location it's game 
> over; I didn't mean to imply otherwise.  I'm saying that since supervisord 
> might potentially import anything in its site-packages dir, this is just less 
> code for you to worry about that might have security bugs in it.
> 
> One specific example of how you might do this is by specifying a 
> protocol-defined codec; if you ever do .decode(user_data) on a string you're 
> doing an attacker-controlled dynamic import.  This is a bug, of course, but a 
> harmless one if you have a small set of modules with no surprises lurking in 
> store.  But, if the attacker can 'import qt' (whose default behavior was to 
> abort() if it couldn't open $DISPLAY for many years, not sure if it still is) 
> from the system, or anything like that, you have potential crashes on your 
> hands.
> 
 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 

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

[Glyph Lefkowitz]

> On Feb 16, 2016, at 5:00 PM, Noah Kantrowitz  > wrote:
> 
> 
>> On Feb 16, 2016, at 4:46 PM, Glyph Lefkowitz > > wrote:
>> 
>>> 
>>> On Feb 16, 2016, at 4:33 PM, Noah Kantrowitz >> > wrote:
>>> 
>>> 
 On Feb 16, 2016, at 4:27 PM, Glyph Lefkowitz > wrote:
 
 
> On Feb 16, 2016, at 4:13 PM, Noah Kantrowitz  > 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.

I don't think users who install supervisord necessarily think they ought to be 
able to import supervisord.  If they do expect that, they should probably 
revise their expectations.

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.

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

Once malicious code is installed in a root-executable location it's game over; 
I didn't mean to imply otherwise.  I'm saying that since supervisord might 
potentially import anything in its site-packages dir, this is just less code 
for you to worry about that might have security bugs in it.

One specific example of how you might do this is by specifying a 
protocol-defined codec; if you ever do .decode(user_data) on a string you're 
doing an attacker-controlled dynamic import.  This is a bug, of course, but a 
harmless one if you have a small set of modules with no surprises lurking in 
store.  But, if the attacker can 'import qt' (whose default behavior was to 
abort() if it couldn't open $DISPLAY for many years, not sure if it still is) 
from the system, or anything like that, you have potential crashes on your 
hands.

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

Re: [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  wrote:
> 
>> 
>> On Feb 16, 2016, at 4:33 PM, Noah Kantrowitz  wrote:
>> 
>> 
>>> On Feb 16, 2016, at 4:27 PM, Glyph Lefkowitz  
>>> wrote:
>>> 
>>> 
 On Feb 16, 2016, at 4:13 PM, Noah Kantrowitz  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

Re: [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  > wrote:
> 
> 
>> On Feb 16, 2016, at 4:27 PM, Glyph Lefkowitz > > wrote:
>> 
>> 
>>> On Feb 16, 2016, at 4:13 PM, Noah Kantrowitz >> > 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/

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

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

[Noah Kantrowitz]

> On Feb 16, 2016, at 4:27 PM, Glyph Lefkowitz  wrote:
> 
> 
>> On Feb 16, 2016, at 4:13 PM, Noah Kantrowitz  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. Virtualenv is a project-centric view of the world 
which breaks down for stuff that is actually global like system command line 
tools. Compare with `npm install -g grunt-cli`.

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

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

[Glyph Lefkowitz]

> On Feb 16, 2016, at 4:13 PM, Noah Kantrowitz  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?

-glyph___
Distutils-SIG maillist  -  Distutils-SIG@python.org
https://mail.python.org/mailman/listinfo/distutils-sig