Only write portable paths in RECORD

[konstin]

The spec allows both, but we're already using forward paths for paths that are not created by uv.

See

• Name of entity from importlib.metadata.files inconsistent between win and linux platforms #14446
• PackagePath does not support Windows paths python/importlib_metadata#528

Closes #14446

[EliteTK]

I read some of the background on this, but despite the fact that we were conformant before and are conformant now, it seems like a breaking change...?

[konstin]

I read some of the background on this, but despite the fact that we were conformant before and are conformant now, it seems like a breaking change...?

Both are valid formats for transporting the same information, we're only really changing the normalization of the data we write, so no workflows should break (plus we fix importlib.metadata compatibility)

[EliteTK]

I didn't mean to imply that we shouldn't change it, I think this is strictly a good change. I just mean that, just like importlib.metadata relied on pip's decision to always use portable paths, someone might have relied on uv's decision to use windows paths on windows.

But, having thought about it a bit more, I agree it's probably too unlikely to make much noise about it beyond the issue title (which is perfectly clear as is).

[konstin]

That's true; Given that pip always wrote portable paths, I hope that no parser reads just the uv format in a non-portable way. With the spec allowing portable paths and Windows applications usually understanding forward slashes, I'm confident enough that we don't need to consider this a breaking change.