Skip to content
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

Check write permissions before downloading any files #1048

Closed
ncoghlan opened this issue Jul 14, 2013 · 14 comments
Closed

Check write permissions before downloading any files #1048

ncoghlan opened this issue Jul 14, 2013 · 14 comments
Labels
auto-locked Outdated issues that have been locked by automation C: logging Information Logging

Comments

@ncoghlan
Copy link
Member

The error message when the user doesn't have write permissions to the installation directory isn't very clear, and doesn't happen until after pip has done a fair bit of work.

It should do an early check for write permissions, and if they aren't available, produce an error message along the lines of the following (for a system install):

"Cannot install to this location: no write permissions for '<site-packages>'. Consider using '--user' or a virtual environment."

For a user install or a virtual environment install, the message would just be the first sentence (since we have no helpful suggestions to offer in that case):

"Cannot install to this location: no write permissions for '<site-packages>'.

@dstufft
Copy link
Member

dstufft commented Jul 14, 2013

I agree with the implementation as Nick puts it here. It doesn't change the default (which would be a change in behavior), but it directs users to a possibility of virtual environments or the user packages.

@qwcode
Copy link
Contributor

qwcode commented Oct 24, 2013

at one point, this got the PEP439 label. Are we considering this critical for PEP453, or just nice to have. It sure is time, we did something about this.

@dstufft
Copy link
Member

dstufft commented Oct 24, 2013

Nice to have, not critical.

@ncoghlan
Copy link
Member Author

Would definitely be nice, but not a blocker. The only blocker identified so
far is the requests issue with out of date certificate data.

@qwcode
Copy link
Contributor

qwcode commented Oct 26, 2013

It should do an early check for write permissions

that's pretty complicated it seems for pip, given pip just subprocesses to setuptools install.
pip install offers --install-option which allows users to pass anything to setuptools, including

--prefix
--exec-prefix
--home
--user
--install-base
--install-platbase
--root
--install-purelib
--install-platlib
--install-lib
--install-headers
--install-scripts
--install-data

3 thoughts:

  1. setuptools could do this check, and return a certain exit code for pip to detect.
  2. pip could try to instantiate an install command directly for this (which pip doesn't normally do) with all the options, and get the targets to check that way.
  3. the "silly" approach of just having pip scrape output for certain exception strings and at least interpret what has happened for people, even if it's not an early check.

@qwcode
Copy link
Contributor

qwcode commented Oct 26, 2013

another thought is for pip to only try do this pre-check for the normal case (i.e. without special options), which would handle 99% of these permission exceptions.

@qwcode
Copy link
Contributor

qwcode commented Oct 26, 2013

for the normal case (i.e. without special options)

but I guess pydistutils.cfg files could be lurking with special options, and we'd be checking the wrong thing.

@ncoghlan
Copy link
Member Author

It's worth asking Jason about setuptools doing the early check, after it has figured out all the relevant details.

Alternatively, just extracting the logic to check for the existence of pydistutils.cfg files (which I didn't know were a possibility until reading the previous comment) and whether or not any relevant parameters are set would still solve the usability problem for beginners.

@ncoghlan
Copy link
Member Author

Oh, the other option is for setuptools to expose the "find install path" logic as a usable API (but that may not be feasible due to the arcana that is the distutils command system).

@dstufft
Copy link
Member

dstufft commented Nov 5, 2013

I think this should be bumped from the 1.5 timeline. It's not a blocker and I believe it's got significant enough work to be done in it that it's unlikely to happen. Any objections?

@qwcode
Copy link
Contributor

qwcode commented Nov 5, 2013

I agree. to do it right, it's a bit of work unfortunately.

@dstufft
Copy link
Member

dstufft commented Nov 5, 2013

Ok, then i'm gonna drop this off of 1.5 then.

@jogo
Copy link

jogo commented Aug 10, 2015

Looks like this has been open for some time now with know progress, any updates?

@dstufft
Copy link
Member

dstufft commented Mar 22, 2017

Closing this, as once we implement #1668 we should not typically run into permission errors where it makes sense to spend time implementing this.

@dstufft dstufft closed this as completed Mar 22, 2017
@lock lock bot added the auto-locked Outdated issues that have been locked by automation label Jun 3, 2019
@lock lock bot locked as resolved and limited conversation to collaborators Jun 3, 2019
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
auto-locked Outdated issues that have been locked by automation C: logging Information Logging
Projects
None yet
Development

No branches or pull requests

4 participants