-
-
Notifications
You must be signed in to change notification settings - Fork 130
Add a cron job for testing third-party users of typing_extensions #206
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Conversation
|
Links to the |
d368b9b to
284a6f4
Compare
|
Thanks, this is great! I'll wait for some time in case the maintainers of these libraries have some feedback. |
srittau
left a comment
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Thanks! This is very useful.
Co-authored-by: Sebastian Rittau <[email protected]>
srittau
left a comment
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
LGTM, but I haven't reviewed the actual implementation.
Co-authored-by: Jelle Zijlstra <[email protected]> Co-authored-by: Sebastian Rittau <[email protected]>
Fixes #198.
As well as the packages suggested by Jelle in #198, I also added
typeguardandcattrs. Both are popular packages that usetyping_extensionsextensively.typeguard, as you can see by the CI on this PR, is currently broken by the same change that brokepydantic,typing_inspectandtyped-argument-parse(reimplementingLiteralon 3.8 and 3.9, as well as 3.7).cattrswasn't broken by v4.6.0, but given the way they're peering into our internals, it wouldn't surprise me if we broke them at some point.Note that while the
typeguardfailures show the usefulness of having a CI job like this, thetyped-argument-parsertests are currently passing despite us apparently having broken them. That shows the limits of a CI job like this: we're dependent on third-party projects having reasonable test coverage, or this won't help us much.I didn't include
beartype, as their CI is currently failing on theirmainbranch, their CI setup is somewhat complicated, and they don't fully supporttyping_extensionsanyway.My thinking is that if a third-party test starts failing:
Literalchange), we immediately skip the test in CI, open an issue over at the third-party project, and unskip the test as soon as the issue is fixed in the third-party project. A release shouldn't necessarily be considered blocked if a test is skipped, but we should at least make the third-party project aware of the breakage before the release, and give them a reasonable amount of time to fix it before we cut a release.