[Python-Dev] 3.5 release schedule PEP

[Donald Stufft]

> On Sep 25, 2014, at 6:44 PM, Chris Barker <chris.barker at noaa.gov> wrote:
> 
> On Thu, Sep 25, 2014 at 9:00 AM, Donald Stufft <donald at stufft.io <mailto:donald at stufft.io>> wrote:
> 1) Just always default to —user and add a —system or similar flag, this
>     is super easy to change but is a backwards incompatible change and
>     would need to go through a deprecation window.
> 
> Maybe would have been the way to go to begin with, but I think backwards compatibility should probably trump "better" -- even with a deprecation window.
>  
> 2) Switch to —user based on if the user has permission to write to the
>     site-packages or not.
> 
> ouch -- no. Why not a clear error message if pip can't write to site-packages -- something like:
> 
> """
> pip doesn't have permissions to write to the system location. If you want to install this package system-wide, you need to run pip with admin priviledges (and example here if it's easy), if you want to install for this user only, pass the "--user" flag to pip install
> """ 
> 
> "In the face of ambiguity, refuse the temptation to guess.”

I fairly strongly believe that the current default is doing a great disservice
to users. I believe that for *most* people --user is the correct option for
them to be using and the fact that it's not the default and requires opt in
is a historical artifact more than anything else.

Immediately switching to --user as a default (outside of a virtual environment)
would break two important use cases:

- A root/admin user attempting to install into a global site-packages
- A user who uses complete Python installations to isolate themselves such as
  those created by pyenv.

It would techincally break anyone relying on the fact that pip will currently
throw an error if you attempt to ``pip install`` something without sudo,
however I do not consider that to be an actual use case that is going to have
wide signifcance.

So we get down to how do we not break the two important use cases above. At
first I thought about detecting uid 0 (and something similar on Windows?) and
turning off the --user default in those cases. However that still left us
dealing with something for the second use case.

After thinking about it I realized there isn't a good way to determine if
something is a user controlled Python installation instead of a system
controlled one. This lead me to the realization that something that could be
used to "detect" this is whether or not the current user has the ability to
write to the site-packages as a means of determining "is my current user
allowed to manage that particular Python".

Either way I'm fairly commited to making --user the default, the only question
on my mind is what exactly does that look like (e.g. does root get --user by
default?) and how we get from where we are now to that point. I think that
raising an error here is fairly unfriendly when we can know with pretty good
certainity what the user wanted (and they can explicitly declare that if they
want too).

However this particular thing is somewhat offtopic for this list and the
particulars of pip moving to --user by default is best discussed on our issue
tracker here: https://github.com/pypa/pip/issues/1668.

---
Donald Stufft
PGP: 7C6B 7C5D 5E2B 6356 A926 F04F 6E3C BCE9 3372 DCFA

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/python-dev/attachments/20140925/505acb99/attachment.html>