setuptools.setup Complete partially Unknown method and fix Command type variance issue

[Avasam]

Resolves #15146 (comment) introduced in that same PR.

[github-actions]

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

[henryiii]

Hopefully this fixes the issue with setuptools.setup now returning Any in 80.9.0.20251221. (Seen in scikit-build/scikit-build-core#1198)

[srittau]

I don't think it will fix the return type. We might need an overload for the case where distclass is not defined, although the type var has a default. Cc @Avasam

[Avasam]

Ugh, doing an overload here will be annoying, but maybe I'll have to. I don't think I can even use non-closed TypedDict unpacking (from https://peps.python.org/pep-0728/) here.

I wonder why pyright and pyrefly infer correctly but neither mypy nor ty does.
Edit: I somehow misread, mypy is clearly shown to be giving the correct return type in my screenshot.
The TypeVar is bound and has a default, I fully expected the return type to have a known lower-bound.

I think pyright takes into account the default assignement whereas the other two don't

[srittau]

Yes, it seems to me that the type checkers should use the default here.

[Avasam]

Idk how I managed to misread it and post a screenshots. But actually isn't it showing that the return type isn't Any on mypy if omitting distclass ?

I just checked https://github.com/scikit-build/scikit-build-core/blob/main/src/scikit_build_core/setuptools/wrapper.py and the issue there is that **kw: Any explicitly, so the inferred distclass is also Any, so checkers infer Any as the return type.

@henryiii Making scikit_build_core.setuptools.wrapper.setup's return type generic based on distclass like we're doing here would fix your no-any-return and make it more accurate to runtime.

So I think that's actually a true positive.