-
-
Notifications
You must be signed in to change notification settings - Fork 366
Unbreak CI (3.14 + cython) #3264
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
Codecov Report✅ All modified and coverable lines are covered by tests. Additional details and impacted files@@ Coverage Diff @@
## main #3264 +/- ##
===================================================
+ Coverage 99.93727% 99.93728% +0.00001%
===================================================
Files 126 126
Lines 19129 19132 +3
Branches 1296 1296
===================================================
+ Hits 19117 19120 +3
Misses 10 10
Partials 2 2
🚀 New features to boost your workflow:
|
an alternate fix for cython is to disable line traces, but that will disable coverage |
ubuntu 3.14 now failed with a segfault I haven't seen in previous runs: https://github.com/python-trio/trio/actions/runs/14970947768/job/42051585863?pr=3264#step:6:1277
|
@slow | ||
# see comment on test_static_tool_sees_all_symbols | ||
@pytest.mark.redistributors_should_skip | ||
@pytest.mark.skipif( |
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.
Same here
managed to minify the repro to import trio
from contextlib import suppress
import gc
def test_error_in_run_loop() -> None:
# Blow stuff up real good to check we at least get a TrioInternalError
async def main() -> None:
task = trio.lowlevel.current_task()
task._schedule_points = "hello!" # type: ignore
await trio.lowlevel.checkpoint()
with suppress(trio.TrioInternalError):
trio.run(main)
gc.collect()
gc.collect() # removing this line makes the segfault disappear but I only get it when running through pytest. Modifying it to directly run the function body without invoking pytest does not give any segfault. It should be possible to minify it further and recreate the exceptions that are happening inside trio, and maybe some way of unrolling the pytest stack. |
It would be a good idea to create a cpython issue for that just so they know it's a thing. |
opened python/cpython#133932 |
…r_in_run_loop, add overeager strict xfail on export tests
There's a more proper fix for cython than pinning it: cython/cython#6865 (comment) |
uh, did I somehow break CI or is github acting up? |
( | ||
endsWith(matrix.python, '-dev') | ||
|| endsWith(matrix.python, '-nightly') | ||
|| matrix.python == '3.14' |
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.
IMO it's cleaner to use 3.14-dev because it's implied that we should change it back once 3.14 stable is released.
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.
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.
It still fails but then it's allowed to. (I think that run failed because the Ubuntu and MacOS failures, not the Windows one)
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.
It still fails but then it's allowed to. (I think that run failed because the Ubuntu and MacOS failures, not the Windows one)
uh, this is the error:
Version 3.14-dev.0-alpha - 3.14-dev.X was not found in the local cache
Error: The version '3.14-dev.0-alpha - 3.14-dev.X' with architecture 'x86' was not found for Windows 2022.
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.
Oops, I wasn't able to see the logs. We should probably remove that logic near setup-python(I think it's only there because legacy) but for now this new thing is fine too.
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.
you're very right, I confused myself from some git blame
ing.
But regardless, let's just merge this as is to unblock other PRs and we can possibly clean this up later?
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.
I personally don't like that allow-prereleases
input of actions/setup-python
and use 3.14-dev
or more often ~3.14.0-0
to have it represent that it's not yet stable explicitly.
One day, I'll show you my reusable-tox.yml
thing which will simplify this by a lot...
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.
I think allow-prereleases
is fine, since basically it saves some unnecessary churn (we should be pretty sure Trio will not need changes before switching 3.14-dev
to 3.14
) and allows marking some versions as allowed to fail just based on the version scheme.
Is there a trap to be aware of?
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.
It's just that you're forced to keep updating the conditional on this line which is disconnected from the version string, even though they are tightly coupled through the concept of pre-releases. That's two places to keep in sync already with a visually unobvious link. This is what I consider mental overhead. The same churn just worse.
Having "allow-failures" in the same identifier allows being intentional about expecting a version to fail or not.
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.
To be clear the only reason we had to update the conditional on this line is because some other legacy logic -- we don't actually have allow-prereleases
but instead some text interpolation to emulate the effects. The downside of the text interpolation is that we can't support 3.14-dev
, so we if switched to allow-prereleases
we would have the same behavior as currently except that 3.14-dev
would work.
And then since we have a continue-on-error
we can use the version identifier to signal whether failure is allowed (3.14-dev
will allow failure, 3.14
won't). This way we can actually make use of the fact that Python tries not to break anything after they start releasing betas (by switching to 3.14
) while not having to switch the identifier whenever a stable version comes out.
I'm for some reason not getting mypy fails locally, but disabling
test_static_tool_sees_all_symbols
entirely for 3.14.0b1 rather than trying to dig into why that might be the caseI'm also getting cffi/OpenSSL segfaults locally on 3.14, but that doesn't seem to impact CI so we can probs ignore that one for now