[srittau]

No description provided.

[AlexWaygood]

Hmm, what problem is this fixing? I see lots of stdlib stubtest failures on recent pushes main, but I don't see pyright failing at all

[srittau]

See here, for example: https://github.com/python/typeshed/actions/runs/12013896148/job/33488465170?pr=11709

Cf. #11709

[AlexWaygood]

Huh, that's very odd... Has it been happening on any other PRs that you know of?

[srittau]

I've merged the latest changes for the unnecessary allowlist entries into a few PRs. Let's see what happens.

[AlexWaygood]

Okay, it's not really a flake: the pyright: ignore is consistently needed on main but consistently not needed on that PR.

It's because that PR adds stubs that depend on django-stubs, and django-stubs depends on tomli. So that PR pulls tomli into the environment and means that pyright can resolve the import in the setuptools stubs. So the pyright failure in that PR is a side effect of the fact that we have no isolation between stubs packages when we test them with pyright in CI -- all non-types dependencies get installed into one big "venv soup".

[srittau]

Indeed. The question is how to solve it. Maybe we just depend on tomli in requirements for Python < 3.11?

[AlexWaygood]

Alternatively... we could maybe just delete this module from the stubs? It seems like an implementation detail at runtime to me; I'm not sure it's meant to be for public consumption. It's probably not worth the bother to maintain stuff like this? @Avasam, what do you think?

[github-actions]

According to mypy_primer, this change has no effect on the checked open source code. 🤖🎉

[Avasam]

I concur with Alex' assessment of the CI failure.

And yes setuptools.compat is intended to be private pypa/setuptools#4609 (comment) & https://github.com/jaraco/skeleton/blob/gh-pages/index.md#compatibility-modules
Unless we have a niche case where a type in setuptools.compat is used for typing and the two branches differs in a meaningful way, I think we can remove these modules from typeshed.