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 <deb...@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 <d...@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 > _______________________________________________ Python-modules-team mailing list Python-modules-team@lists.alioth.debian.org http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/python-modules-team
