Bump setuptools to 69.0.* #11069
Bump setuptools to 69.0.* #11069
Conversation
Co-authored-by: Avasam <samuel.06@hotmail.com>
This comment has been minimized.
This comment has been minimized.
|
I don't see a better solution. This is basically the same as when we create a shim for classes/methods we can't import. So we at least get the correct signatures. |
Co-authored-by: Avasam <samuel.06@hotmail.com>
|
According to mypy_primer, this change has no effect on the checked open source code. 🤖🎉 |
There was a problem hiding this comment.
As mentioned in a previous comment:
I don't see a better solution [without introducing a change or special-casing in mypy/stubtest or stubuploader]. This is basically the same as when we create a shim for classes/methods we can't import. So we at least get the correct signatures.
Not the most straightforward PR to start with as a new maintainer :P But if you feel confident this doesn't need anyone else's review I'll go ahead and merge.
Indeed not, but you're hardly new around here, eh ;) |
Closes #11049
Closes #11066 (cc. @Avasam -- but I've listed you as a co-author, as I used your work for the second commit here :)
Here's the problem:
packaging(aspkg_resources._vendor.packaging)setuptools's vendored version ofpackagingincludes apy.typedfile in that directory, which causes stubtest to get confused when comparingpkg_resources._vendor.packagingin the stub withpkg_resources._vendor.packagingat runtime (see the failing CI in [stubsabot] Bump setuptools to 69.0.* #11049)pkg_resources._vendor.packagingfrom the stub, and just declare that the stubs have a dependency onpackaging. That doesn't pass our CI, however, becausepackagingisn't in the stub-uploader's allowlist -- and even if it were, it wouldn't pass our CI, becausesetuptoolsdoesn't declare a dependency onpackagingat runtime (it doesn't need to, since it vendorspackaging). See the failing CI in Update setuptools to v69 #11066.The "ridiculously dumb" solution is to continue vendoring
packagingin the stubs, much assetuptoolsdoes at runtime. But instead of putting the vendored version ofpackagingin apkg_resources._vendor.packagingdirectory (as it is at runtime), put it in apkg_resources._vendored_packagingdirectory instead.