Wheel cache is disable because ~ is not expanded

[jaimeMF]

I have this configuration file:

[global]
cache-dir=~/.cache/pip

The cache is disabled:

$ pip3 --version
pip 7.1.1 from /usr/local/lib/python3.4/site-packages (python 3.4)
$ pip3 install -U ipython
The directory '~/.cache/pip' or its parent directory is not owned by the current user and caching wheels has been disabled. check the permissions and owner of that directory. If executing pip with sudo, you may want sudo's -H flag.
Requirement already up-to-date: ipython in /usr/local/lib/python3.4/site-packages
Requirement already up-to-date: pexpect in /usr/local/lib/python3.4/site-packages (from ipython)
Requirement already up-to-date: simplegeneric>0.8 in /usr/local/lib/python3.4/site-packages (from ipython)
Requirement already up-to-date: gnureadline in /usr/local/lib/python3.4/site-packages (from ipython)
Requirement already up-to-date: appnope in /usr/local/lib/python3.4/site-packages (from ipython)
Requirement already up-to-date: decorator in /usr/local/lib/python3.4/site-packages (from ipython)
Requirement already up-to-date: pickleshare in /usr/local/lib/python3.4/site-packages (from ipython)
Requirement already up-to-date: traitlets in /usr/local/lib/python3.4/site-packages (from ipython)
Requirement already up-to-date: path.py in /usr/local/lib/python3.4/site-packages (from pickleshare->ipython)
Requirement already up-to-date: ipython-genutils in /usr/local/lib/python3.4/site-packages (from traitlets->ipython)

But if I explicitly write the cache path with the user folder expanded it's enabled:

pip3 install -U ipython
Collecting ipython
  Using cached ipython-4.0.0-py3-none-any.whl
Requirement already up-to-date: pexpect in /usr/local/lib/python3.4/site-packages (from ipython)
Requirement already up-to-date: traitlets in /usr/local/lib/python3.4/site-packages (from ipython)
Requirement already up-to-date: decorator in /usr/local/lib/python3.4/site-packages (from ipython)
Requirement already up-to-date: simplegeneric>0.8 in /usr/local/lib/python3.4/site-packages (from ipython)
Requirement already up-to-date: appnope in /usr/local/lib/python3.4/site-packages (from ipython)
Requirement already up-to-date: pickleshare in /usr/local/lib/python3.4/site-packages (from ipython)
Requirement already up-to-date: gnureadline in /usr/local/lib/python3.4/site-packages (from ipython)
Requirement already up-to-date: ipython-genutils in /usr/local/lib/python3.4/site-packages (from traitlets->ipython)
Requirement already up-to-date: path.py in /usr/local/lib/python3.4/site-packages (from pickleshare->ipython)
Installing collected packages: ipython
Successfully installed ipython-4.0.0

[xavfernandez]

Not sure about the wheel caching disabling (since the check is currently done after passing it to the wheel cache, cf aa0099a) but there is an issue indeed:

$ python -c "from pip.utils import filesystem; print(filesystem.check_path_owner('~/.cache/pip'))"
None
$ python -c "from pip.utils import filesystem; print(filesystem.check_path_owner('/home/xfernandez/.cache/pip'))"
True

Not sure if we should expand in the method or outside but since:

In [2]: os.path.lexists('~/.cache/pip')
Out[2]: False
In [3]: os.path.lexists('/home/xfernandez/.cache/pip')                                                                                          
Out[3]: True

There is something to fix indeed, thanks for the report :)

[pfmoore]

pip is quite inconsistent in where we expand ~. Originally, I think it wasn't expanded anywhere, but there were some PRs that added ~-expansion in certain places. Someone should probably go through and make the behaviour consistent throughout. I suspect the best approach would be to have an expand_filename function that's called on all user-supplied names, and use full explicit pathnames everywhere internally. Any changes to expansion behaviour would then be centralised in one place.

The annoying part of such a change would be going through and making sure we catch every case :-)

[xavfernandez]

Yup, #981 approach seems cleaner.

[dstufft]

Closing this as a duplicate of #980, which should handle generically supporting path expansion.