You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
Repository navigation
stubtest unused allowlist for third party stubs #5654
How does this work currently? In #5652, I found that in a third-party stub, I needed to delete unused entries to make stubtest pass. But there's still .github/workflows/stubtest-unused-allowlist.yml, which is for stdlib only. So it's fine to leave unused stdlib entries in a PR, but not for third-party libraries.
Why the inconsistency? Can we unify this somehow so that it actually makes sense?
Yeah, I would prefer to accept unused allow lists in third-party stubs as well to keep friction as low as possible and then integrate it into the (weekly?) cron job.
I just didn't add a Github action for automatically cleaning up third party stubtest allowlists. Once we have that, should be fine to use --ignore-unused-allowlist in stubtest_third_party.py.
The logic for cleaning up third party allowlists should be pretty simple, since we only have one allowlist (as opposed to the common + python version + platform combination + etc that we have for stdlib).
Activity
srittau commentedon Jun 16, 2021
Yeah, I would prefer to accept unused allow lists in third-party stubs as well to keep friction as low as possible and then integrate it into the (weekly?) cron job.
[-]stubtest unused allowlist[/-][+]stubtest unused allowlist for third party stubs[/+]hauntsaninja commentedon Jun 16, 2021
I just didn't add a Github action for automatically cleaning up third party stubtest allowlists. Once we have that, should be fine to use
--ignore-unused-allowlistinstubtest_third_party.py.The logic for cleaning up third party allowlists should be pretty simple, since we only have one allowlist (as opposed to the common + python version + platform combination + etc that we have for stdlib).
Akuli commentedon Dec 5, 2021
We ended up going in a different direction in #6406.