New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Default to --user #1668

Open
dstufft opened this Issue Mar 21, 2014 · 136 comments

Comments

Projects
None yet
@dstufft
Member

dstufft commented Mar 21, 2014

When pip is installed on a system that has an OS Python install there is currently a problem where pip install foo will throw an error because it doesn't have file permissions. This causes people to instead run sudo pip install foo which globally installs to the system Python. This creates an issue where people are using pip to manage system level packages when they should likely be using the system package manager.

So my intention is that pip should default to --user however there are a few sticking points with this:

  • How does this interact with Windows? Does this make sense there?
  • How does this interact with altinstall'd Pythons? Specially such as are installed with tools like https://github.com/yyuu/pyenv
  • What do we do for when people do invoke pip as root? Installing into /root/.local/ does not seem very useful.
  • What does this mean for get-pip and the pypa install instructions?
  • ~/.local/bin is not on many people's $PATH, is there anything that can be done about this?
  • --user installs lack precedence to global easy_install'd packages, which can be quite unexpected.

There are a number of issues that are relevant here: #624 #1443 #1153 #1500 #1051

/cc @ncoghlan

@qwcode

This comment has been minimized.

Show comment
Hide comment
@qwcode

qwcode Mar 21, 2014

Contributor

What does this mean for the pypa install instructions?

currently the mention of root or Administrator access is in a footnote, so the instructions would fundamentally stay the same (assuming get-pip automatically defaulted to --user as well). the change would be to explain that they will end up with installs that only apply to their current user.

regardless of the --user change, the current instructions need to explain that some distributions like debian, are disabling ensurepip, so they shouldn't go looking for it as a way to get pip.

Contributor

qwcode commented Mar 21, 2014

What does this mean for the pypa install instructions?

currently the mention of root or Administrator access is in a footnote, so the instructions would fundamentally stay the same (assuming get-pip automatically defaulted to --user as well). the change would be to explain that they will end up with installs that only apply to their current user.

regardless of the --user change, the current instructions need to explain that some distributions like debian, are disabling ensurepip, so they shouldn't go looking for it as a way to get pip.

@dstufft

This comment has been minimized.

Show comment
Hide comment
@dstufft

dstufft Mar 21, 2014

Member

Long term I'm pretty sure they are going to keep it enabled, they are just figuring out how to do it.

Member

dstufft commented Mar 21, 2014

Long term I'm pretty sure they are going to keep it enabled, they are just figuring out how to do it.

@qwcode

This comment has been minimized.

Show comment
Hide comment
@qwcode

qwcode Mar 21, 2014

Contributor

although this issue is described as being about where pip should manage packages by default, almost more important (to me at least) is that this is indirectly about where get-pip will place pip by default.

Contributor

qwcode commented Mar 21, 2014

although this issue is described as being about where pip should manage packages by default, almost more important (to me at least) is that this is indirectly about where get-pip will place pip by default.

@qwcode

This comment has been minimized.

Show comment
Hide comment
@qwcode

qwcode Mar 21, 2014

Contributor

How does this interact with altinstall'd Pythons?
Specially such as are installed with tools like https://github.com/yyuu/pyenv

the user scheme is .local/lib/pythonX.Y/site-packages, so if you're managing multiple pythons with the same major/minor version, you could end up with a mess I guess.

for tools like that, that manage real pythons, pinning pip to global mode would make sense for those.

Contributor

qwcode commented Mar 21, 2014

How does this interact with altinstall'd Pythons?
Specially such as are installed with tools like https://github.com/yyuu/pyenv

the user scheme is .local/lib/pythonX.Y/site-packages, so if you're managing multiple pythons with the same major/minor version, you could end up with a mess I guess.

for tools like that, that manage real pythons, pinning pip to global mode would make sense for those.

@dstufft

This comment has been minimized.

Show comment
Hide comment
@dstufft

dstufft Mar 21, 2014

Member

A relevant issue on the redhat/fedora bug tracker https://bugzilla.redhat.com/show_bug.cgi?id=662034#c10

Member

dstufft commented Mar 21, 2014

A relevant issue on the redhat/fedora bug tracker https://bugzilla.redhat.com/show_bug.cgi?id=662034#c10

@dstufft

This comment has been minimized.

Show comment
Hide comment
@dstufft

dstufft Mar 21, 2014

Member

It looks like for Fedora/RedHat PATH=$PATH:$HOME/.local/bin:$HOME/bin is already in their /etc/skel/.bash_profile. This would make stuff installed with --user still show up by default, at least for bash users (default shell). Maybe other distros already have this?

Member

dstufft commented Mar 21, 2014

It looks like for Fedora/RedHat PATH=$PATH:$HOME/.local/bin:$HOME/bin is already in their /etc/skel/.bash_profile. This would make stuff installed with --user still show up by default, at least for bash users (default shell). Maybe other distros already have this?

@pfmoore

This comment has been minimized.

Show comment
Hide comment
@pfmoore

pfmoore Mar 21, 2014

Member

There's nothing specially different about Windows that I know of. But we've only just got the standard Python directory onto people's PATH, I don't expect that getting a per-user scripts directory on is going to be particularly easy - and there may be technical difficulties as well, I'm not sure putting a user-level environment variable like %LOCALAPPDATA% into the system-level %PATH% even works :-(

I'm against rushing this. I would prefer waiting till we've had more experience with user installs and have managed to iron out the issues first. I know that's a chicken and egg problem, but I don't see rushing into a change as helping.

Also, with my Windows hat on, I'd have to say that making it harder for Unix users who haven't yet worked out that careless use of sudo is bad to do stupid things, isn't really that good a justification...

I'm assuming that this would only apply when running pip from a system Python.

Member

pfmoore commented Mar 21, 2014

There's nothing specially different about Windows that I know of. But we've only just got the standard Python directory onto people's PATH, I don't expect that getting a per-user scripts directory on is going to be particularly easy - and there may be technical difficulties as well, I'm not sure putting a user-level environment variable like %LOCALAPPDATA% into the system-level %PATH% even works :-(

I'm against rushing this. I would prefer waiting till we've had more experience with user installs and have managed to iron out the issues first. I know that's a chicken and egg problem, but I don't see rushing into a change as helping.

Also, with my Windows hat on, I'd have to say that making it harder for Unix users who haven't yet worked out that careless use of sudo is bad to do stupid things, isn't really that good a justification...

I'm assuming that this would only apply when running pip from a system Python.

@dstufft

This comment has been minimized.

Show comment
Hide comment
@dstufft

dstufft Mar 21, 2014

Member

Well the different thing on Windows is there isn't a system provided Python like there is on *nix that also comes with system provided Python packages :)

I'm not particularly wanting to rush this either. I just wanted to start the discussion.

This doesn't really affect people who type sudo pip install as I think installing something as root should still go to the system site packages by default. This would be to guide people towards using --user when running as an unprivileged user. Right now what you get is that pip install as a regular user just bombs out with a permission error. Even if we improve that message to bomb out and suggest --user that's still not the greatest UX.

In talking to one of the Fedora people, I think the way it may make to do this is to implement a permissions check. If I have permission to write to the site-packages directory then I am a privledged user and pip installs to the global Python, If I do not then I am an unprivileged user and it installs to --user.

Member

dstufft commented Mar 21, 2014

Well the different thing on Windows is there isn't a system provided Python like there is on *nix that also comes with system provided Python packages :)

I'm not particularly wanting to rush this either. I just wanted to start the discussion.

This doesn't really affect people who type sudo pip install as I think installing something as root should still go to the system site packages by default. This would be to guide people towards using --user when running as an unprivileged user. Right now what you get is that pip install as a regular user just bombs out with a permission error. Even if we improve that message to bomb out and suggest --user that's still not the greatest UX.

In talking to one of the Fedora people, I think the way it may make to do this is to implement a permissions check. If I have permission to write to the site-packages directory then I am a privledged user and pip installs to the global Python, If I do not then I am an unprivileged user and it installs to --user.

@ncoghlan

This comment has been minimized.

Show comment
Hide comment
@ncoghlan

ncoghlan Mar 21, 2014

Member

As far as Windows goes, we usually duck the problem because we install Python to a non-privileged directory by default, so pip doesn't trigger UAC when installing globally. If someone changes that to install into Program Files instead, then UAC will trigger when they run pip (which is also OK). I'm not sure what happens if they select a per-user install in the installer.

As Paul notes, PATH on Windows doesn't include the user scripts directory yet (just the global one), so that's definitely worth taking into account.

I don't see any major barriers on the POSIX side though. How does this UX idea sound: for wheel based installs, check for permissions on the installation target directory, and if the user doesn't have write permissions, put up a prompt asking if they would like to do a --user install instead? A new "--global" or "--system" flag would force the "no" answer.

And then at some point in the future, we could skip the prompt and simply assume --user if the permissions weren't right for a global install.

Member

ncoghlan commented Mar 21, 2014

As far as Windows goes, we usually duck the problem because we install Python to a non-privileged directory by default, so pip doesn't trigger UAC when installing globally. If someone changes that to install into Program Files instead, then UAC will trigger when they run pip (which is also OK). I'm not sure what happens if they select a per-user install in the installer.

As Paul notes, PATH on Windows doesn't include the user scripts directory yet (just the global one), so that's definitely worth taking into account.

I don't see any major barriers on the POSIX side though. How does this UX idea sound: for wheel based installs, check for permissions on the installation target directory, and if the user doesn't have write permissions, put up a prompt asking if they would like to do a --user install instead? A new "--global" or "--system" flag would force the "no" answer.

And then at some point in the future, we could skip the prompt and simply assume --user if the permissions weren't right for a global install.

@dstufft

This comment has been minimized.

Show comment
Hide comment
@dstufft

dstufft Mar 21, 2014

Member

A prompt (except in the case of --no-input) probably makes sense for the transition step. I think checking permissions should make things work for Windows too since by default the location is in a spot where people have permissions on and so the only time they'd hit this would be if they are using a systems admin provided Python that explicitly didn't give them permission.

Essentially this makes our failure mode much better.

Member

dstufft commented Mar 21, 2014

A prompt (except in the case of --no-input) probably makes sense for the transition step. I think checking permissions should make things work for Windows too since by default the location is in a spot where people have permissions on and so the only time they'd hit this would be if they are using a systems admin provided Python that explicitly didn't give them permission.

Essentially this makes our failure mode much better.

@qwcode

This comment has been minimized.

Show comment
Hide comment
@qwcode

qwcode Mar 21, 2014

Contributor

making it harder for Unix users who haven't yet worked out that careless use of sudo
is bad to do stupid things, isn't really that good a justification..

sudo and security is really a secondary issue IMO.
this is primarily about preventing the conflict between OS packaging and pip in the system python.
Currently, linux users are often placed in an impossible situation.

  1. OS Mandate: 'Use the OS pkg mgr; Don't infect your system with roque pip-installed packages (including a get-pip'd pip)'
  2. Reality: "The OS packages (including pip) are too old, and I can't upgrade to the experimental release of the distro, just to get upgrades of some package. I'm going rogue...."
Contributor

qwcode commented Mar 21, 2014

making it harder for Unix users who haven't yet worked out that careless use of sudo
is bad to do stupid things, isn't really that good a justification..

sudo and security is really a secondary issue IMO.
this is primarily about preventing the conflict between OS packaging and pip in the system python.
Currently, linux users are often placed in an impossible situation.

  1. OS Mandate: 'Use the OS pkg mgr; Don't infect your system with roque pip-installed packages (including a get-pip'd pip)'
  2. Reality: "The OS packages (including pip) are too old, and I can't upgrade to the experimental release of the distro, just to get upgrades of some package. I'm going rogue...."
@qwcode

This comment has been minimized.

Show comment
Hide comment
@qwcode

qwcode Mar 21, 2014

Contributor

another baby step is to document (assuming we test it) that you can get-pip.py --user, and have the PUG mention --user as a possibility for the install of virtualenv (and wheel, and twine too, if not in a virtualenv)

Contributor

qwcode commented Mar 21, 2014

another baby step is to document (assuming we test it) that you can get-pip.py --user, and have the PUG mention --user as a possibility for the install of virtualenv (and wheel, and twine too, if not in a virtualenv)

@ncoghlan

This comment has been minimized.

Show comment
Hide comment
@ncoghlan

ncoghlan Mar 21, 2014

Member

FWIW, distro vendors also consider the status quo a problem and are looking at various ways to improve the tools for doing selective upgrades without impacting core OS components. Still worth us tackling from the upstream side though, since those efforts are at various stages of maturity and we want a consistent cross-platform solution for end users.

Member

ncoghlan commented Mar 21, 2014

FWIW, distro vendors also consider the status quo a problem and are looking at various ways to improve the tools for doing selective upgrades without impacting core OS components. Still worth us tackling from the upstream side though, since those efforts are at various stages of maturity and we want a consistent cross-platform solution for end users.

@pfmoore

This comment has been minimized.

Show comment
Hide comment
@pfmoore

pfmoore Mar 22, 2014

Member

I have no problem with changing things to help co-operate with distros on Unix; if defaulting to --user on Unix and not on Windows is acceptable, that's fine with me. I just don't see switching from a bad experience on Unix to a bad experience on Windows as a good trade-off. And I'm yet to be convinced that --user on Windows is ready for prime time.

Note that triggering UAC when running pip is bad on Windows, because what it actually means is that pip won't run except in an elevated console window. It does not mean that pip users get a nice prompt which they can say "OK" to, unfortunately, that's only how GUI apps work...

Member

pfmoore commented Mar 22, 2014

I have no problem with changing things to help co-operate with distros on Unix; if defaulting to --user on Unix and not on Windows is acceptable, that's fine with me. I just don't see switching from a bad experience on Unix to a bad experience on Windows as a good trade-off. And I'm yet to be convinced that --user on Windows is ready for prime time.

Note that triggering UAC when running pip is bad on Windows, because what it actually means is that pip won't run except in an elevated console window. It does not mean that pip users get a nice prompt which they can say "OK" to, unfortunately, that's only how GUI apps work...

@dstufft

This comment has been minimized.

Show comment
Hide comment
@dstufft

dstufft Mar 22, 2014

Member

@pfmoore What do you think the user experience of Windows should be when you pip install something and you don't have permissions to write to the directory?

Member

dstufft commented Mar 22, 2014

@pfmoore What do you think the user experience of Windows should be when you pip install something and you don't have permissions to write to the directory?

@dstufft

This comment has been minimized.

Show comment
Hide comment
@dstufft

dstufft Mar 22, 2014

Member

FWIW I'm totally OK with making this optional depending on Windows or not. I'm just wondering if the check of "Do I have permissions to write to the site-packages folder" check won't achieve that anyways in 99% of installs, and if installing to --user would be a better experience in the fraction of cases where you don't have write permissions to the site-packages directory.

In other words, if we check permissions the proposal isn't replacing global install with a user install, it's replacing a permission error with a --user install.

Member

dstufft commented Mar 22, 2014

FWIW I'm totally OK with making this optional depending on Windows or not. I'm just wondering if the check of "Do I have permissions to write to the site-packages folder" check won't achieve that anyways in 99% of installs, and if installing to --user would be a better experience in the fraction of cases where you don't have write permissions to the site-packages directory.

In other words, if we check permissions the proposal isn't replacing global install with a user install, it's replacing a permission error with a --user install.

@qwcode

This comment has been minimized.

Show comment
Hide comment
@qwcode

qwcode Mar 22, 2014

Contributor

the proposal isn't replacing global install with a user install
it's replacing a permission error with a --user install

ok, but recall that the permissions check idea (#1048) won't the be the easiest thing

Contributor

qwcode commented Mar 22, 2014

the proposal isn't replacing global install with a user install
it's replacing a permission error with a --user install

ok, but recall that the permissions check idea (#1048) won't the be the easiest thing

@dstufft

This comment has been minimized.

Show comment
Hide comment
@dstufft

dstufft Mar 22, 2014

Member

It'll be pretty easy in the Wheel case, and we can get the 99.9% case covered with sdists, it should only be a problem in setup.py's that do really funky things.

Member

dstufft commented Mar 22, 2014

It'll be pretty easy in the Wheel case, and we can get the 99.9% case covered with sdists, it should only be a problem in setup.py's that do really funky things.

@pfmoore

This comment has been minimized.

Show comment
Hide comment
@pfmoore

pfmoore Mar 22, 2014

Member

What do you think the user experience of Windows should be when you pip install something and you don't have permissions to write to the directory?

Well, being able to write to the site-packages directory is so rare on Windows that I'm not sure how relevant the question is in practice. But if it happened, I would say that an error saying "system site-packages is not writeable - did you mean to use --user?" would be the sensible approach.

Actually, I think that would be better on Unix as well. Switching the behaviour depending on writeability is bizarre, and it's not clear to me if using --user for a personally-built Python in a writeable directory is the right approach (but I have precisely zero experience of such a setup, so I don't have anything to back that opinion up).

Suggestion: Start with an error suggesting --user as above. Once people are using --user more commonly, and we have more experience with it, then let's consider switching the default.

Member

pfmoore commented Mar 22, 2014

What do you think the user experience of Windows should be when you pip install something and you don't have permissions to write to the directory?

Well, being able to write to the site-packages directory is so rare on Windows that I'm not sure how relevant the question is in practice. But if it happened, I would say that an error saying "system site-packages is not writeable - did you mean to use --user?" would be the sensible approach.

Actually, I think that would be better on Unix as well. Switching the behaviour depending on writeability is bizarre, and it's not clear to me if using --user for a personally-built Python in a writeable directory is the right approach (but I have precisely zero experience of such a setup, so I don't have anything to back that opinion up).

Suggestion: Start with an error suggesting --user as above. Once people are using --user more commonly, and we have more experience with it, then let's consider switching the default.

@ncoghlan

This comment has been minimized.

Show comment
Hide comment
@ncoghlan

ncoghlan Mar 22, 2014

Member

The approach Paul suggests is roughly what I had in mind, but with a yes/no prompt rather than bailing out with an error message. There are pros & cons to those two approaches (mostly relating to how they fail when invoked from another script).

Member

ncoghlan commented Mar 22, 2014

The approach Paul suggests is roughly what I had in mind, but with a yes/no prompt rather than bailing out with an error message. There are pros & cons to those two approaches (mostly relating to how they fail when invoked from another script).

@rkuska

This comment has been minimized.

Show comment
Hide comment
@rkuska

rkuska Mar 24, 2014

Would it be possible to add to Python something like sys.localprefix (I see python-dev here)?
Sys.localprefix would be default to sys.prefix. Distros could define it same way as they define prefix (e.g. prefix = '/usr', localprefix='/usr/local'). Pip and easy_install would use sys.localprefix as a location to install to if used as sudo, if they don't have sufficient rights fall back to --user.

rkuska commented Mar 24, 2014

Would it be possible to add to Python something like sys.localprefix (I see python-dev here)?
Sys.localprefix would be default to sys.prefix. Distros could define it same way as they define prefix (e.g. prefix = '/usr', localprefix='/usr/local'). Pip and easy_install would use sys.localprefix as a location to install to if used as sudo, if they don't have sufficient rights fall back to --user.

@bkabrda

This comment has been minimized.

Show comment
Hide comment
@bkabrda

bkabrda Mar 24, 2014

We've done something like this with "gem install" in Fedora 17 and Ruby devels were generally very satisfied about it, so I thought I'd share:

  • "gem install foo" installs "foo" into ~/somedir if uid != 0
  • "gem install foo" installs "foo" into /usr/local/somedir if uid == 0
  • "yum install rubygem-foo" installs RPM-packaged "foo" into /usr/somedir

I think that choosing install dir based on user privileges would be very confusing for people; "pip install foo" should work the same way for all non-root users. If you consider majority of users, they'll want to "pip install" into their home and "sudo pip install" into a system-wide dir. Therefore I think it's the best approach to do this based on uid as shown above - and for those users who are not root but want to install into a system-wide dir, there is always the --target option.

bkabrda commented Mar 24, 2014

We've done something like this with "gem install" in Fedora 17 and Ruby devels were generally very satisfied about it, so I thought I'd share:

  • "gem install foo" installs "foo" into ~/somedir if uid != 0
  • "gem install foo" installs "foo" into /usr/local/somedir if uid == 0
  • "yum install rubygem-foo" installs RPM-packaged "foo" into /usr/somedir

I think that choosing install dir based on user privileges would be very confusing for people; "pip install foo" should work the same way for all non-root users. If you consider majority of users, they'll want to "pip install" into their home and "sudo pip install" into a system-wide dir. Therefore I think it's the best approach to do this based on uid as shown above - and for those users who are not root but want to install into a system-wide dir, there is always the --target option.

@Ivoz

This comment has been minimized.

Show comment
Hide comment
@Ivoz

Ivoz Mar 24, 2014

Member

@bkabrda that's an easy choice to make as long as you're not worried about adding scripts to $PATH. What have you done there?

Member

Ivoz commented Mar 24, 2014

@bkabrda that's an easy choice to make as long as you're not worried about adding scripts to $PATH. What have you done there?

@bkabrda

This comment has been minimized.

Show comment
Hide comment
@bkabrda

bkabrda Mar 24, 2014

@Ivoz as noted by @dstufft, Fedora already has $HOME/.local/bin on PATH, so everything worked out of the box (speaking of scripts).

bkabrda commented Mar 24, 2014

@Ivoz as noted by @dstufft, Fedora already has $HOME/.local/bin on PATH, so everything worked out of the box (speaking of scripts).

@ncoghlan

This comment has been minimized.

Show comment
Hide comment
@ncoghlan

ncoghlan Mar 24, 2014

Member

Slavek's suggestion sounds good to me for POSIX systems. It should also work nicely with containers, since stuff running in a container can be told to think it is uid 0, even though it's something else entirely from outside the container.

For Windows, I'm less sure what the right answer is. We don't have quite the same problem with getting into an argument with the system package manager, although it does exist to some degree (pip install vs MSI installers), and have the additional complication that even in Python 3.4, the installer's optional PATH modifications only add the global Scripts directory, not the per-user one.

Windows also has weirdness based on whether Python is installed to the default location (uncontrolled) or into Program Files (UAC privilege escalation needed to make changes).

Member

ncoghlan commented Mar 24, 2014

Slavek's suggestion sounds good to me for POSIX systems. It should also work nicely with containers, since stuff running in a container can be told to think it is uid 0, even though it's something else entirely from outside the container.

For Windows, I'm less sure what the right answer is. We don't have quite the same problem with getting into an argument with the system package manager, although it does exist to some degree (pip install vs MSI installers), and have the additional complication that even in Python 3.4, the installer's optional PATH modifications only add the global Scripts directory, not the per-user one.

Windows also has weirdness based on whether Python is installed to the default location (uncontrolled) or into Program Files (UAC privilege escalation needed to make changes).

@felixonmars

This comment has been minimized.

Show comment
Hide comment
@felixonmars

felixonmars Mar 24, 2014

The "localprefix" idea suggested by @rkuska looks nice to me, simple and easy. Also I really like the approach @bkabrda suggests, especially for distros like Arch that make python 3.x the default python.

One more note is, Arch has disabled ensurepip in the 3.4.0 release just like Debian (mostly because we want to provide latest versions of setuptools and pip, while the bundled versions may be outdated for ages), so it would be nice to have a tip for it.

@lvoz
For Arch we didn't add any path under $HOME to PATH, but I still think it fine. We already have wiki entry for Ruby that tells the user to add it.

felixonmars commented Mar 24, 2014

The "localprefix" idea suggested by @rkuska looks nice to me, simple and easy. Also I really like the approach @bkabrda suggests, especially for distros like Arch that make python 3.x the default python.

One more note is, Arch has disabled ensurepip in the 3.4.0 release just like Debian (mostly because we want to provide latest versions of setuptools and pip, while the bundled versions may be outdated for ages), so it would be nice to have a tip for it.

@lvoz
For Arch we didn't add any path under $HOME to PATH, but I still think it fine. We already have wiki entry for Ruby that tells the user to add it.

@ncoghlan

This comment has been minimized.

Show comment
Hide comment
@ncoghlan

ncoghlan Mar 24, 2014

Member

It would be nice if rather than just disabling it, the Arch and Debian developers would help Slavek work on his patch to have ensurepip reconstruct a wheel from the system versions and install that into virtual environments.

Member

ncoghlan commented Mar 24, 2014

It would be nice if rather than just disabling it, the Arch and Debian developers would help Slavek work on his patch to have ensurepip reconstruct a wheel from the system versions and install that into virtual environments.

@bkabrda

This comment has been minimized.

Show comment
Hide comment
@bkabrda

bkabrda Mar 24, 2014

Just FYI, we already have working Python 3.4 RPM builds in Fedora's Copr build system (testing, not advisable to install them if you don't want to break anything). If you want to know more about how we approach this, have a look at the code etc, see my discussion with Barry Warsaw [2] at debian-python ML.
(Our patches still need some love before we propose them upstream, but everything works ok for us downstream ATM)

[1] http://copr-fe.cloud.fedoraproject.org/coprs/bkabrda/python-3.4/
[2] https://lists.debian.org/debian-python/2014/03/msg00046.html

bkabrda commented Mar 24, 2014

Just FYI, we already have working Python 3.4 RPM builds in Fedora's Copr build system (testing, not advisable to install them if you don't want to break anything). If you want to know more about how we approach this, have a look at the code etc, see my discussion with Barry Warsaw [2] at debian-python ML.
(Our patches still need some love before we propose them upstream, but everything works ok for us downstream ATM)

[1] http://copr-fe.cloud.fedoraproject.org/coprs/bkabrda/python-3.4/
[2] https://lists.debian.org/debian-python/2014/03/msg00046.html

@felixonmars

This comment has been minimized.

Show comment
Hide comment
@felixonmars

felixonmars Mar 24, 2014

Sorry, but AFAIK Arch never supported wheel, nor do we want to make ensurepip invoke package manager (correct me if I understand this approach wrong, though).

For ensurepip, it would be a nice idea to warn the user not to install pip using ensurepip though, and that's the most I can think of for now.

felixonmars commented Mar 24, 2014

Sorry, but AFAIK Arch never supported wheel, nor do we want to make ensurepip invoke package manager (correct me if I understand this approach wrong, though).

For ensurepip, it would be a nice idea to warn the user not to install pip using ensurepip though, and that's the most I can think of for now.

@ncoghlan

This comment has been minimized.

Show comment
Hide comment
@ncoghlan

ncoghlan Nov 15, 2017

Member

As a concrete next step, I broke out a separate issue for the addition of a --global flag: #4865

Member

ncoghlan commented Nov 15, 2017

As a concrete next step, I broke out a separate issue for the addition of a --global flag: #4865

@jakirkham

This comment has been minimized.

Show comment
Hide comment
@jakirkham

jakirkham May 13, 2018

This is almost certainly a bad idea in virtualenv or conda environments. Whatever gets installed in .local when one environment is active could easily break another environment. So what's the thinking in those cases?

cc @msarahan @kalefranz

jakirkham commented May 13, 2018

This is almost certainly a bad idea in virtualenv or conda environments. Whatever gets installed in .local when one environment is active could easily break another environment. So what's the thinking in those cases?

cc @msarahan @kalefranz

@ncoghlan

This comment has been minimized.

Show comment
Hide comment
@ncoghlan

ncoghlan May 13, 2018

Member

This issue doesn't apply when inside an active virtual environment - it solely applies when no active environment is detected, and none of the target definition options (--prefix, --root, etc) have been given on the command line.

Member

ncoghlan commented May 13, 2018

This issue doesn't apply when inside an active virtual environment - it solely applies when no active environment is detected, and none of the target definition options (--prefix, --root, etc) have been given on the command line.

@jakirkham

This comment has been minimized.

Show comment
Hide comment
@jakirkham

jakirkham May 13, 2018

How is this being determined?

jakirkham commented May 13, 2018

How is this being determined?

@kalefranz

This comment has been minimized.

Show comment
Hide comment
@kalefranz

kalefranz May 13, 2018

We've been considering disabling by default ~/.local on sys.path for python inside conda environments, which by definition happens to be any python installed by conda. It's tricky though. Either way we might end up violating expectations of a group of users. Discussion at conda/conda#7173

kalefranz commented May 13, 2018

We've been considering disabling by default ~/.local on sys.path for python inside conda environments, which by definition happens to be any python installed by conda. It's tricky though. Either way we might end up violating expectations of a group of users. Discussion at conda/conda#7173

@ssbarnea

This comment has been minimized.

Show comment
Hide comment
@ssbarnea

ssbarnea Jun 29, 2018

Contributor

Wasn't pip able to load any argument from environment variables starting with PIP_? Does this work for --user? What would be the full variable name?

Contributor

ssbarnea commented Jun 29, 2018

Wasn't pip able to load any argument from environment variables starting with PIP_? Does this work for --user? What would be the full variable name?

@pradyunsg

This comment has been minimized.

Show comment
Hide comment
@pradyunsg
Member

pradyunsg commented Jun 29, 2018

@ssbarnea

This comment has been minimized.

Show comment
Hide comment
@ssbarnea

ssbarnea Jun 29, 2018

Contributor

PIP_USER=yes to be exact, thanks! Using environment variables is much easier for CI usage as you only have to define them once and they will be used whenever the commands are called.

Contributor

ssbarnea commented Jun 29, 2018

PIP_USER=yes to be exact, thanks! Using environment variables is much easier for CI usage as you only have to define them once and they will be used whenever the commands are called.

@ssbarnea

This comment has been minimized.

Show comment
Hide comment
@ssbarnea

ssbarnea Jun 30, 2018

Contributor

I had to do some really ugly logic for travis where apparently some stages are run as normal user without virtualemv and some inside a virtualenv, and you have no idea which one it would be.

inside virtualenv is likely that —user will fail if you didnt use site-packages (which is causing other problems).

This ment that I hade to detect virtualenv in bash and avoid adding the —user or the run will fail.

This is ugly and caused me to waste a lot of time debugging, i am sure others will face the same.

I think we need an option that activates a fallback regarding installation: like install it on user if you can and fallback to system.

pip should fail only if fails to find a place to install a package.

Contributor

ssbarnea commented Jun 30, 2018

I had to do some really ugly logic for travis where apparently some stages are run as normal user without virtualemv and some inside a virtualenv, and you have no idea which one it would be.

inside virtualenv is likely that —user will fail if you didnt use site-packages (which is causing other problems).

This ment that I hade to detect virtualenv in bash and avoid adding the —user or the run will fail.

This is ugly and caused me to waste a lot of time debugging, i am sure others will face the same.

I think we need an option that activates a fallback regarding installation: like install it on user if you can and fallback to system.

pip should fail only if fails to find a place to install a package.

@mixmastamyk

This comment has been minimized.

Show comment
Hide comment
@mixmastamyk

mixmastamyk Jul 27, 2018

Any movement on this?

I didn't see it mentioned, but perhaps pip should complain if --user is passed when run under sudo.

mixmastamyk commented Jul 27, 2018

Any movement on this?

I didn't see it mentioned, but perhaps pip should complain if --user is passed when run under sudo.

@yoosofan

This comment has been minimized.

Show comment
Hide comment
@yoosofan

yoosofan Aug 30, 2018

These unsolved issues lead programmers away from pip and even python and force them to use other packages or even other programming languages like javascript and npm with less issues like this. For a new starter who wants to use python these extra necessary options are frustrating.

yoosofan commented Aug 30, 2018

These unsolved issues lead programmers away from pip and even python and force them to use other packages or even other programming languages like javascript and npm with less issues like this. For a new starter who wants to use python these extra necessary options are frustrating.

@dmikov

This comment has been minimized.

Show comment
Hide comment
@dmikov

dmikov Sep 8, 2018

Why would --user be default? Can not it be specified explicitly? I cannot run pip --target because of that it complains that it cannot be used in conjunction with user. Any idea how to avoid it?

dmikov commented Sep 8, 2018

Why would --user be default? Can not it be specified explicitly? I cannot run pip --target because of that it complains that it cannot be used in conjunction with user. Any idea how to avoid it?

@benoit-pierre

This comment has been minimized.

Show comment
Hide comment
@benoit-pierre

benoit-pierre Sep 8, 2018

Member

@dmikov : it's not the default. Unless your using Debian/Ubuntu broken version, in which case you can workaround --user being automatically set by using: PIP_USER=0 pip install -t .... Or better yet, install an official version and use that.

Member

benoit-pierre commented Sep 8, 2018

@dmikov : it's not the default. Unless your using Debian/Ubuntu broken version, in which case you can workaround --user being automatically set by using: PIP_USER=0 pip install -t .... Or better yet, install an official version and use that.

@ErikBjare

This comment has been minimized.

Show comment
Hide comment
@ErikBjare

ErikBjare Sep 13, 2018

I've dreamed at night of the --user option becoming the default (not kidding), any chance of my dreams coming true anytime soon?

ErikBjare commented Sep 13, 2018

I've dreamed at night of the --user option becoming the default (not kidding), any chance of my dreams coming true anytime soon?

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment