Ambiguity in relative file urls

I would like to point out that the requirements file format specification mentions the ability to set relative path names such as file:../../lib/project#egg=MyProject in the file. Although those who try to use this syntax probably were disappointed, because in fact this variant does not work.

While trying to cope with the problem I discovered that relative urls are not supported “officially” at all, nor in RFC (wikipedia could be the starting point), nor in web browsers which can be considered as “reference implementation”.

In light of that, it would be acceptable to fix the documentation and to forbid explicitly using relative names in packages. On the other hand, it would be useful to accept such format. Personally, I discovered the issue when I tried to create the package and the sample subpackage in its subdirectory. The sample has a bunch of dependencies including “parent package” which I tried to point as file:…/ . I believe this approach does make sense.

I suggest considering my patch 54f5adeae4f9640c6b8d which fixes url_to_path function behavior such that urls starting with file:/ are considered as absolute, whereas urls which don’t have any slash after “file:” are relative ones.

[michaeljones]

Ok, this can be resolved by using file:// instead of just file: which might be more appropriate anyway:

>>> scheme, netloc, path, query, fragment = urlparse.urlsplit('file://somewhere')
>>> urlparse.urlunsplit((scheme, netloc, path, query, None))                                                                                              
'file://somewhere'
>>> scheme, netloc, path, query, fragment = urlparse.urlsplit('file://./somewhere')
>>> urlparse.urlunsplit((scheme, netloc, path, query, None))                                                                                              
'file://./somewhere'

But then we fall afoul of the UNC check here: https://github.com/pypa/pip/blob/develop/pip/download.py#L447

>>> from pip.download import url_to_path
>>> url_to_path('file://somewhere')
'\\\\somewhere'
>>> url_to_path('file://./somewhere')
'\\\\./somewhere'

Could it be worth improving that check? Can we check for the current operating system or any other kind of condition before making that assumption? I’d love some input here as I’m out of my depth. From the little I’ve seen, UNC is a Windows thing and I’m on Linux.

Edit: As a final data point, if I delete that UNC check then it works fine for me with file://somewhere style paths.

[rach]

Hi,

I met the same issue today.

It’s a bit annoying that the behavior are not coherent :

-r …/prod-requirement.txt # is relative to the file …/my-app # is relative to where I launched the command

Is there any workaround at this stage to make work relative path ?

Thanks you