What base URL are relative dependency specifiers resolved against?

[gsnedders]

Issue Description

https://packaging.python.org/en/latest/specifications/dependency-specifiers/ allows a URI_reference:

packaging.python.org/source/specifications/dependency-specifiers.rst

Line 71 in 59dabe8

urlspec = '@' wsp* <URI_reference>

Where URI_reference is defined as:

packaging.python.org/source/specifications/dependency-specifiers.rst

Line 387 in 59dabe8

URI_reference = <URI | relative_ref>

Thus, it is valid to write my-amazing-package @ ../../this-is-a-path.

However, it doesn't appear to be defined what base URL is used to resolve the relative URL, even in the "simple" case of a dependency specifier in a pyproject.toml file.

Code of Conduct

• I am aware that participants in this repository must follow the PSF Code of Conduct.

[ncoghlan]

This also isn't explicitly specified in https://packaging.python.org/en/latest/specifications/version-specifiers/#direct-references or https://packaging.python.org/en/latest/specifications/direct-url-data-structure/

That formally means that the interpretation of relative URLs (whether schemaless or not) is up to the tool doing the resolution, and pip itself rejects them as invalid:

~/devel/venvstacks$ pip install --dry-run venvstacks@../venvstacks
Defaulting to user installation because normal site-packages is not writeable
ERROR: Invalid requirement: 'venvstacks@../venvstacks'
Hint: It looks like a path. File 'venvstacks@../venvstacks' does not exist.

pip also rejects venvstacks@file://../venvstacks (with an exception rather than a dedicated error message), while the absolute file path venvstacks@file://$PWD is processed as a valid direct URL reference.

[gsnedders]

Given I’ve had cases where it would be useful (in a monorepo, wanting to install other packages from within the monorepo), it would be good to specify something here — though we may well need behaviour to depend on where the requirement was loaded from: over HTTP I can well imagine we simply would want to disallow all relative URLs, whereas from FILE the answer might be different.

Though clearly, if package foo has a dependency on bar @ ../bar the wheel one builds can’t be used generally, given the metadata would presumably encode that path (or, I suppose, one could require wheels to always have relative paths resolved, which might at least make them valid for the same system).