`PackagePath` does not support Windows paths

[konstin]

Currently, importlib.metadata.files assumes that path are Unix-style with forward slashes, while the spec allows Windows-style backwards slashes too. This causes e.g. the .name on items to be inconsistent between platforms (astral-sh/uv#14446).

importlib_metadata/importlib_metadata/__init__.py

Line 371 in 95ecf2a

class PackagePath(pathlib.PurePosixPath):

From https://packaging.python.org/en/latest/specifications/recording-installed-packages/#the-record-file

The path may be either absolute, or relative to the directory containing the .dist-info directory (commonly, the site-packages directory). On Windows, directories may be separated either by forward- or backslashes (/ or ).

Ref #51

[jaraco]

I'm sad to see that the specs for the record file allow for backslashes when on Windows. That's a terrible spec. First of all, Windows supports posix-style forward slashes. Second, the RECORD file isn't describing paths on a local file system; it's describing paths relative to the package, a package which is presumably portable. By allowing backslashes but only on one platform, it makes the format non-portable. Why would the spec allow for non-portable formats in a portable spec?

This behavior is tested on multiple platforms, and the behavior is consistent. PackagePath does support paths on Windows - it just supports the portable format.

I contend that this issue should be fixed in the spec - the spec should be updated to require or at least strongly encourage the use of forward slashes to specify the paths.

If the issue cannot be constrained in the spec, it adds a lot of complexity for downstream consumers (including importlib metadata).

Even if there's a reason to keep the spec as stated, I'm not sure it's worth the trouble for importlib-metadata to support these formats. What's the motivation for supporting this platform-specific format? Why should uv not produce posixpath-separated paths like pip does?

[konstin]

I'm with you on improving the spec and would support a change to only allow portable paths in the future, but I find it odd that a standard library module does not support something that's intentionally part of the living spec, or the other way round, that we wrote a spec that doesn't consider std support. We can use portable paths in uv, tbh I'm more surprised that this hasn't shown up in another context before.

[ncoghlan]

I just ran into this myself, with poetry generating absolute paths on Windows (with drive letter prefix and backslashes) and some test code then getting confused until we switched from using the PackagePath outputs directly to instead doing file_path = pathlib.Path(p.locate()) (we're only working with unpacked filesystem installations, so breaking the abstraction layer is a valid assumption in our specific case).

I suspect a lot of consumers would be in a similar situation: they're converting the importlib metadata abstraction to a different format that implicitly fixes up the underlying incorrect behaviour. Combined with pip and tools based on it generating POSIX paths in RECORD regardless of platform, I can see why it hasn't come up as a major problem (I also forgot that the spec allowed Windows style paths until I looked it up. Given how long ago the RECORD format was standardised, my assumption would be that emitting platform dependent paths is what setuptools used to do, and the exact timing of the standardisation was in the window before Jason took over from PJE as the lead maintainer)

[radoering]

I just ran into this myself, with poetry generating absolute paths on Windows (with drive letter prefix and backslashes) and some test code then getting confused

Interesting enough it does not seem to be an issue in Poetry's own code base. If I did not miss anything, Poetry only does this to install the root project in editable mode. And unlike absolute Windows paths with / separators, absolute Windows paths with \ separators seem to work fine with Distribution.files. However, installer, which is used by Poetry to install all the dependencies, writes absolute paths with / as separator, which does not work with Distribution.files on Python 3.10 and 3.11. See #535.