Skip to content
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

#10343 - run tests w/ python 3.11 #11734

Merged
merged 12 commits into from
Nov 5, 2022
Merged

#10343 - run tests w/ python 3.11 #11734

merged 12 commits into from
Nov 5, 2022

Conversation

eevelweezel
Copy link
Contributor

@eevelweezel eevelweezel commented Oct 28, 2022

Scope and purpose

Fixes #10343

Add support for running tests w/ Python 3.11 on Windows, MacOS, and Linux.

@eevelweezel eevelweezel changed the title running tests on 3.11 #10343 - run tests w/ python 3.11 Oct 28, 2022
@eevelweezel
Copy link
Contributor Author

I'd appreciate some guidance. This enables tests in Python 3.11, but there are multiple places where the test suite fails under that version.

@adiroiban
Copy link
Member

Many thanks for creating the PR and your help with 3.11

Yes. I think that is best to create separate tickets and try to fix each error type/class in separate PRs.

I think that we will also need to wait for @glyph to do a new release for automat and then have a PR in twisted that uses the newer version.

@glyph
Copy link
Member

glyph commented Oct 29, 2022

New automat release is out.

@adiroiban
Copy link
Member

I thinks is best to start small and don't use 3.11 as default.

I see pydoctor failing...and we might have other development-only dependencies failing.

The first step is to get at least a subset of Twisted test on 3.11

We don't have to move all the build tools to 3.11, yet.

@adiroiban
Copy link
Member

I see twisted/persisted/aot.py and twisted.spread failing.

If they need only 2 lines of code to fix 3.11 support, we can have the fix in this PR.

Otherwise, I think is best to fix the changes in separate tickets.

@eevelweezel
Copy link
Contributor Author

I see twisted/persisted/aot.py and twisted.spread failing.

If they need only 2 lines of code to fix 3.11 support, we can have the fix in this PR.

Otherwise, I think is best to fix the changes in separate tickets.

I've reverted the commit making 3.11 the default python & fixed the tests for twisted.spread and twisted.persisted.

@glyph
Copy link
Member

glyph commented Nov 3, 2022

Looks like the test fixes have not worked?

@adiroiban
Copy link
Member

FAILED (skips=514, failures=3, successes=10598)

Not bad. This is good progress. Thanks!

@eevelweezel
Copy link
Contributor Author

I looked into the 3 remaining failures. Those also needed only 1-2 lines to fix, so I addressed those here as well.

@eevelweezel
Copy link
Contributor Author

please review

@chevah-robot chevah-robot requested a review from a team November 4, 2022 04:41
@glyph
Copy link
Member

glyph commented Nov 4, 2022

@eevelweezel Thank you so much for doing this critical maintenance!

Copy link
Member

@glyph glyph left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

LGTM

I'd really like to move that .misc to a feature so if anyone has time to do that and land that would be great.

src/twisted/newsfragments/10343.misc Outdated Show resolved Hide resolved
src/twisted/web/test/test_flatten.py Show resolved Hide resolved
@@ -122,11 +122,19 @@ jobs:
# Just Python 3.9 with default settings.
- python-version: '3.9'

# Just Python 3.11 with default settings.
- python-version: '3.11'

# Newest macOS and newest Python supported versions.
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Please update this comment... 3.10 is no longer the newes Python.

The idea with this comment want to highlight that we only run the tests on a single macOS environemnt.

And that environment is newest macos supported by GitHub + newest Python supported by Twisted.

In the past we used to run tests on macOS-11 ...but the GitHub environmet was broken , so we stopped running those tests.

Maybe, we can also just remote these tests, and only run python 3.11 on macOS.

I don't think that we need 2 macOS jobs.

Copy link
Member

@adiroiban adiroiban left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Great job. Thanks.

I am requesting changes due to:

  • release notes
  • test_flatten

Not adding new jobs for macOS and Windows, would be nice.
we already have a big list of jobs.

@glyph glyph requested review from glyph and removed request for glyph November 4, 2022 19:22
@glyph
Copy link
Member

glyph commented Nov 4, 2022

I left off the comments about "newest" just because this is a general cleanup the file needs and nothing to do with 3.11 support. Anywhere we say something like "newest" or "currently supported", we should really be saying "as of" and a date, but I don't want to put the burden of that kind of a fix onto this PR which is really doing something else. I realize that this makes things even more out of date but each PR should fix one thing at a time and "3.11 support" and "none of the comments refer to the current accurate state of our CI" are not really related :).

@@ -122,6 +122,9 @@ jobs:
# Just Python 3.9 with default settings.
- python-version: '3.9'

# Just Python 3.11 with default settings.
- python-version: '3.11'

# Newest macOS and newest Python supported versions.
- python-version: '3.10'
Copy link
Member

@adiroiban adiroiban Nov 4, 2022

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

My suggestion was to use 3.11 here

and also use 3.11 for Windows on line 144

Suggested change
- python-version: '3.10'
- python-version: '3.11'

In this way, we run Windows and macOS python trial tests with latest Python version

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Ah, makes sense. Updated.

"""
),
flags=re.MULTILINE,
),
)
self.assertTrue("RuntimeError: example" in str(failure.value))
Copy link
Member

@adiroiban adiroiban Nov 4, 2022

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I don't think that this is ok.

The previous check already has builtins.RuntimeError: example>> which should be the same thing.

So I don't see any extra value / info / assertion here.

I am not 100% what is the expected output, but as mentioned by Glyph ... getting the same expected regex on 3.11 and other python version would be hard.

As it looks like in 3.11 the default expception rending was changed.

Copy link
Member

@glyph glyph Nov 4, 2022

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Why, exactly, is this not OK?

What we are trying to test for here is that the exception type is relayed somewhere in the message to the user and we have not, in our custom traceback construction logic, accidentally elided or changed it. The previous check does not have RuntimeError in it any more, it was removed, due to the traceback formatting changes. Ostensibly we could check it with an individual assertion, sure, but is it worth any additional effort to figure out exactly what precise logic in Python's traceback formatting changed to offset this slightly differently than it was before? We're testing Twisted's traceback construction, not Python's traceback formatting.

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I guess as long as we're spending so long discussing this line, I could point out that the new assertion loses information, so it would be better to change it to use the unittest idiom for this type of assertion rather than assertTrue (which is almost always the wrong choice and gives no information upon failure)

Suggested change
self.assertTrue("RuntimeError: example" in str(failure.value))
self.assertIn("RuntimeError: example", str(failure.value))

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

The check is not ok as I think that the previous check already does the same thing.

The assertion can be left, it there is no extra coverage for this assertion.

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Read the diff more carefully. The previous check does not check that any more.

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Specifically, from the diff view:
image

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I agree that this should be assertIn vs assertTrue, updated.

Copy link
Member

@adiroiban adiroiban left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Thanks. This can be merged.

I think that assertIn is not really needed as assertRegex already does the same job.

@glyph feel free to merge

Thanks you for your help.

Happy to see 3.11 up and running :)

src/twisted/web/test/test_flatten.py Show resolved Hide resolved
@glyph glyph merged commit a604afd into twisted:trunk Nov 5, 2022
bmwiedemann pushed a commit to bmwiedemann/openSUSE that referenced this pull request Jan 11, 2023
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

Successfully merging this pull request may close these issues.

Get support for Python 3.11
4 participants