fix Distribution.files for Python 3.10 and 3.11 on Windows and add regression tests

[radoering]

Pull Request Check List

See #10904 (comment)

This is especially relevant for the builtin uninstaller (#10904 or #10931).

• Added tests for changed code.
• Updated documentation for changed code.

[sourcery-ai]

Hey - I've found 1 issue, and left some high level feedback:

• The global monkeypatch of importlib_metadata.PathDistribution.locate_file at import time may have surprising side effects for other code in the same process; consider scoping this patch to a helper function or context used only when enumerating site packages instead of applying it unconditionally on import.
• The importlib_metadata.PathDistribution attribute access in the patch is not guarded; if an older/newer importlib_metadata implementation lacks this class, the import block will raise at import time—consider using getattr/hasattr and skipping the patch when the expected API is not present.
• The patched locate_file behavior is hard-coded to self._path.parent / str(path); if possible, add a brief comment explaining why this is correct for all the path forms exercised (relative, absolute, and ..-traversal) so future maintainers understand why this override is safe.

Prompt for AI Agents

Please address the comments from this code review:

## Overall Comments
- The global monkeypatch of `importlib_metadata.PathDistribution.locate_file` at import time may have surprising side effects for other code in the same process; consider scoping this patch to a helper function or context used only when enumerating site packages instead of applying it unconditionally on import.
- The `importlib_metadata.PathDistribution` attribute access in the patch is not guarded; if an older/newer `importlib_metadata` implementation lacks this class, the import block will raise at import time—consider using `getattr`/`hasattr` and skipping the patch when the expected API is not present.
- The patched `locate_file` behavior is hard-coded to `self._path.parent / str(path)`; if possible, add a brief comment explaining why this is correct for all the path forms exercised (relative, absolute, and `..`-traversal) so future maintainers understand why this override is safe.

## Individual Comments

### Comment 1
<location path="src/poetry/utils/env/site_packages.py" line_range="41-42" />
<code_context>
+        pass
+    else:
+
+        def _patched_locate_file(
+            self: importlib_metadata.PathDistribution, path: str | os.PathLike[str]
+        ) -> SimplePath:
+            return self._path.parent / str(path)
</code_context>
<issue_to_address>
**issue (bug_risk):** Avoid using `os.PathLike` in a runtime annotation when `os` is only imported under `TYPE_CHECKING`.

`_patched_locate_file`’s annotation uses `os.PathLike`, but `os` is only imported under `TYPE_CHECKING`. Without postponed evaluation of annotations, this will raise a `NameError` when the function is defined. Either import `os` at runtime, or change the annotation (e.g. quote it or use `PathLike` from `typing`) so it doesn’t depend on `os` at runtime.
</issue_to_address>

---

Sourcery is free for open source - if you like our reviews please consider sharing them ✨

• X
• Mastodon
• LinkedIn
• Facebook

_{Help me be more useful! Please click 👍 or 👎 on each comment and I'll use the feedback to improve your reviews.}

[sourcery-ai]

issue (bug_risk): Avoid using os.PathLike in a runtime annotation when os is only imported under TYPE_CHECKING.

_patched_locate_file’s annotation uses os.PathLike, but os is only imported under TYPE_CHECKING. Without postponed evaluation of annotations, this will raise a NameError when the function is defined. Either import os at runtime, or change the annotation (e.g. quote it or use PathLike from typing) so it doesn’t depend on os at runtime.

[radoering]

Is this a runtime annotation although we have "from future import annotations" at the top of the module?

[sourcery-ai]

Good catch – you’re right to point that out.

If from __future__ import annotations is present at the top of this module, then all annotations in the file (including _patched_locate_file’s os.PathLike parameter) are stored as strings and not evaluated at function definition time. That means they don’t require os to be available at runtime and won’t raise NameError.

So, under that condition, my original comment about a runtime annotation is not applicable: using os.PathLike in the signature is safe even though os is imported only in the TYPE_CHECKING block.

If you want to be extra explicit, you could:

• either import os unconditionally, or
• switch to PathLike from os via a typing import and keep it only for type checkers,

but that’s stylistic rather than required.

In short: with from __future__ import annotations in place, you’re fine as-is and this is not a bug risk.

[dosubot]

Related Knowledge

1 document with suggested updates is ready for review.

Python Poetry

CHANGELOG /poetry/blob/main/CHANGELOG.md — ⏳ Awaiting Merge

^{How did I do? Any feedback?}