when uninstalling, look for the case of paths containing symlinked directories

[qwcode]

here's the fix I'd prefer for #3141 (as opposed to #3142)

It updates UninstallPathSet.add to deal with the case of paths containing symlinked directories.

this doesn't undo #2552.

I'll admit some possible regrets on merging #2552 which caused this, but I still logically think it's the right thing.

[qwcode]

@pfmoore any advice on backporting os.path.samefile for windows <3.2 (see the description)

[qwcode]

@AvdN do you mind confirming this fix works for you as well? much appreciated if you can.

[AvdN]

@qwcode I can confirm this works for me as well.

In the end (after more than 1.5 hrs) I ended up cloning your repo, and switching to the branch issue_3011 to test this. Gathering the information from this page ( starting with the proper git remote add, seems impossible for someone with a limited VCS/DVCS experience (30/10y respectively))

[pfmoore]

@qwcode well, all os.path.samefile does in 3.4 is compare st.ino and st.dev from the stat structure. It's os.stat that has been updated to give useful ino/dev values in Python 3.4+

From 3.2 to 3.4, os.path.samefile just checked the filename (using _getfinalpathname, which may do a few extra things like resolve symlinks, I haven't checked). But honestly, I think that testing if the (normalised absolute) pathname matches is as good as you're going to get on <3.2 (short of ctypes or C code).

[qwcode]

on 2nd thought, a samefile check isn't right here, because hard links report true for this, but they can be deleted independently.

[qwcode]

sorry, @AvdN , I should have pasted some quick instructions for testing it : )

[qwcode]

ok, I've updated this again with new logic based on this comment #3154 (comment)

see the new description.

I've tested locally (in addition to the automated tests) for the known case (#3011 (comment)), but if people want to test, then here's the commands to install this branch

virtualenv  mytestVE
source mytestVE/bin/activate
pip install -e git+https://github.com/qwcode/pip@issue_3011#egg=pip

[qwcode]

cc @takluyver since this relates to your #2552.

[takluyver]

@qwcode Thanks for ccing me.

I'm having trouble trying to follow the logic in this PR, but from the description in #3141, I think it should be sufficient to normalise paths by resolving links in all but the last component:

join(realpath(dirname(p)), basename(p))

Since #2552 was only concerned with the complete path referring to a symlink, this shouldn't break it.

I think the code in this PR could fall down if you have a path where the whole path is a symlink, and a prefix of it is also a symlink:

/blah/blah/symlink_to_dir/blah/blah/symlink_to_file

Since islink() will be True on the whole path, you'll never normalise the earlier symlink. But I may be missing something.

[qwcode]

thanks @takluyver . I think you're right about how this can break. I'll make another update.

[qwcode]

@takluyver , how about now?

[qwcode]

this is secondary, I just added this, because we had no unit test for this

[takluyver]

That definitely looks easier to understand. A couple of thoughts:

• You probably want to pass tail through normcase(), since it's now bypassing normalize_path(), to ensure equivalent filenames on case-insensitive filesystems match.
• I added the resolve_symlinks parameter to normalize_path in Don't follow symlinks when uninstalling files #2552. If no other uses have been added, you may want to remove it again now that it's not called here. On the other hand, it's not much extra complexity, and it's conceivable that it may one day be useful again.

[qwcode]

ok, normcase added. good point.

as for the extra kwarg, yea, it's ok to leave IMO. might be used later.

[takluyver]

👍 from me

[mathieulongtin]

Works on my end. Thanks!