[Python-modules-team] Bug#771794: pip silently removes/updates system provided python packages

[Donald Stufft]

I'm on my phone so forgive my formatting. 

4, 3, 2 I think in order of best to worst in my opinion. 

I have another question. If we fix this in the upcoming pip 6 release what is the chances of getting an exception for pip 6 in the freeze? If I can solve the problem in pip proper and keep the delta between different platforms smaller I can juggle around priorities and push the other big ticket thing I was working on till another release. 

I have more questions regarding what a good upstream solution looks like but I'll touch on those when I'm back at my desk. 


> On Dec 2, 2014, at 3:41 PM, Scott Kitterman <debian at kitterman.com> wrote:
> 
> On Tuesday, December 02, 2014 12:37:40 PM Donald Stufft wrote:
>>> On Dec 2, 2014, at 12:25 PM, Daniel Kahn Gillmor <dkg at fifthhorseman.net>
>>> wrote:> 
>>>> On 12/02/2014 11:51 AM, Donald Stufft wrote:
>>>> I'd very much prefer it if you didn't do this. This *is* going to break
>>>> things for people and it's going to cause a bunch of confusion.
>>> 
>>> It's not clear to me which side you're arguing for.  can you clarify
>>> which action is going to break things for people and cause a bunch of
>>> confusion?
>>> 
>>> If pip silently removes/updates system-provided python packages, that is
>>> likely to break things and cause a bunch of confusion, no?
>>> 
>>> alternately, if pip verbosely refuses to run as uid 0, that's at least a
>>> non-silent failure. (though it certainly will break things and frustrate
>>> some people)
>>> 
>>>    --dkg
>> 
>> I’m saying don’t make the change. There are major software systems that
>> rely on the ability to install things as root using pip. Chef, puppet, etc.
>> 
>> It’s also going to cause a bunch of confusion because all of a sudden pip
>> is going to have a vastly different behavior if it’s running on Debian vs
>> if it’s running somewhere else. That’s going to blow back on us (the pip
>> maintainers) as we get bug reports from people who assume we broke their
>> use cases for pip.
>> 
>> We (pip maintainers) recognize this can cause issues and we’d like to
>> arrive a solution that solves this issue without introducing major
>> divergence between various platforms and with respect towards the use cases
>> that need or require that ability. It’s somewhat of a thorny problems to do
>> it correctly, we’re a fairly small team with limited time, and we have
>> bigger issues of concern that have taken a front seat.
> 
> In the meantime, we have a release to get out the door, so wait for upstream 
> to figure it out in TBD timeframe isn't a particularly palatable option.
> 
> As package maintainers, I think we have a limited set of options available:
> 
> 1.  Do nothing for now.  Maybe upstream figures out something in time to get a 
> fix in for Jessie.  Maybe the release team decides to ignore the bug for 
> Jessie.  Maybe the release team removes pip for Jessie.
> 
> 2.  Disable root/system use.
> 
> 3.  Make install as --user default and require some suitable named option for 
> root/system install.
> 
> 4.  Install as root by default if permissions allow, but default to --user if 
> not instead of just erroring out.
> 
> As upstream, do you have a preference if it's not #1?  Are there other options 
> that would be better?
> 
> Scott K
>