False positive when checking for inconsistent setup script path on Windows

[uranusjr]

> python setup.py develop
running develop
Checking .pth file support in C:\project\venv\Lib\site-packages\
C:\project\venv\Scripts\pythonw.exe -E -c pass
TEST PASSED: C:\project\venv\Lib\site-packages\ appears to support .pth files
error: ("Can't get a consistent path to setup script from installation directory", 'c:\\project\\', 'c:\\project')

I am not sure what exactly is the cause (I did not have this problem previously, but suddenly sees it when coming back to work on an old project), but it seems to come from a quirk of realpath():

>>> import os
>>> os.path.realpath('.')
'C:\\Users\\uranusjr\\'
>>> os.path.realpath('../')
'C:\\Users\\'
>>> os.path.realpath('..')
'C:\\Users'

[pganssle]

@uranusjr Can you provide a minimal reproducing example for this? It seems that the error is being raised from here, based on the error message, but without a failing test or a minimal reproducing example, it's hard to tell how to fix it.

[uranusjr]

Of course!

> mkdir project
> cd project
> mkdir src
> [create setup.py]

from setuptools import find_packages, setup

setup(
    name='project',
    version='0.0.0',
    package_dir={'': 'src'},
    packages=find_packages('src'),
)

> python setup.py develop
running develop
Checking .pth file support in C:\Users\uranusjr\Documents\playground\project\.venv\Lib\site-packages\
C:\Users\uranusjr\Documents\playground\project\.venv\Scripts\pythonw.exe -E -c pass
TEST PASSED: C:\Users\uranusjr\Documents\playground\project\.venv\Lib\site-packages\ appears to support .pth files
error: ("Can't get a consistent path to setup script from installation directory", 'c:\\users\\uranusjr\\documents\\playground\\project\\', 'c:\\users\\uranusjr\\documents\\playground\\project')

[uranusjr]

I did some digging and it seems the most straightforward fix is to call an additional os.path.normpath in normalize_path to normalise the trailing slash:

def normalize_path(filename):
    """Normalize a file/dir name for comparison purposes"""
    return os.path.normcase(os.path.normpath(os.path.realpath(filename)))

This seems reasonable based on the function’s docstring, but I am not sure how accurate it is, and whether the change would have more implications.

[pganssle]

I think based on the file's docstring, it makes sense to add the additional normpath call in there, since these should compare equal. For example, pathlib has them compare equal:

>>> pathlib.Path("path/to/file") == pathlib.Path("path/to/file/")
True

[davidism]

I can reproduce this. Have been working to move ItsDangerous and MarkupSafe to a src directory structure, and became unable to do pip install -e . for them on Windows. It works fine on Linux. Tox has no problem building an sdist and installing them in its testing envs on either platform.

[zmwangx]

Just experienced this myself when I upgraded to Python 3.7.1. This is due to a regression in ntpath.abspath in 3.7.1 — bpo-31047, and addressed in GH-10082, which has already landed. But the damage is done. Seeing that this is a Python regression, I'm not sure what's the best resolution either.

[pganssle]

@zmwangx I think we're just waiting on a final approval on PR #1521, then the issue can be resolved.

[zmwangx]

Oh I missed the PR. Thanks for the pointer.