fixing e501 for tests/commands by JohananOppongAmoateng · Pull Request #2688 · beeware/briefcase

JohananOppongAmoateng · 2026-02-16T13:21:52Z

This pr is a continuation of fixes for the e501 issues in #2383

PR Checklist:

All new features have been tested
All new features have been documented
I have read the CONTRIBUTING.md file
I will abide by the code of conduct

freakboy3742

Thanks for those updates - looks like more good progress towards clean Ruff output.

I've flagged a few places where the formatting is valid, but needs an update to be consistent with our internal style. I've also flagged a couple of places where the style choices are a bit odd. If those places are the result of automated update from Ruff, then we'll live with the output of that tool - but if they're manually applied choices, in most cases, the older syntax is preferred.

freakboy3742 · 2026-02-17T04:11:42Z

tests/commands/base/test_update_cookiecutter_cache.py

+            "\n    stderr: '\nfatal: could not clone repository"
+            " 'https://example.com' \n'",


As noted in the past PR - when we've got a string as one argument of many, it's preferable to use bracket notation to highlight that this is one string argument, not two:

Suggested change

"\n stderr: '\nfatal: could not clone repository"

" 'https://example.com' \n'",

(

"\n stderr: '\nfatal: could not clone repository"

" 'https://example.com' \n'"

),

freakboy3742 · 2026-02-17T04:12:13Z

tests/commands/base/test_update_cookiecutter_cache.py

+            "\n    stderr: '\nfatal: Could not read from remote repository.\n\nPlease"
+            " make sure you have the correct access rights\nand the repository"
+            " exists. \n'",
+            "Could not read from remote repository.\n\nPlease make sure "
+            "you have the correct access rights\nand the repository exists.",


As above - these two should be bracket-wrapped

freakboy3742 · 2026-02-17T04:12:24Z

tests/commands/base/test_update_cookiecutter_cache.py

+            "\n    stderr: '\nfatal: unable to access 'https://example.com/': "
+            "OpenSSL/3.2.2: error:0A000438:SSL routines::tlsv1 alert internal error'",
+            "Unable to access 'https://example.com/': OpenSSL/3.2.2: "
+            "error:0A000438:SSL routines::tlsv1 alert internal error.",


As above - these two should be bracket-wrapped

freakboy3742 · 2026-02-17T04:15:01Z

tests/commands/create/test_create_app.py

+        f"The directory {bundle_path.relative_to(base_path)} already exists; overwrite"
+        " [y/N]? "


Examples like this one are a bit of a judgement call as to whether extra parentheses are needed, as it's a list with one item; I'd be inclined to they should, to reinforce that it's a single prompt in a list.

(Similarly for the 2 other equivalent changes in this file)

freakboy3742 · 2026-02-17T04:17:29Z

tests/commands/create/test_install_stub_binary.py

        filename=tmp_path
-        / "data/stub/986428ef9d5a1852fc15d4367f19aa328ad530686056e9d83cdde03407c0bceb/My-Stub.zip",
+        / "data/stub/986428ef9d5a1852fc15d4367f19aa328ad530686056e9d83cdde03407c0bceb/My-Stub.zip",  # noqa: E501


Preference here would be (a) to use brackets to clarify the scope of the filename argument, and (b) to break the string in more places to avoid the need for the noqa. Github won't let me code suggest here, but something like:

filename=( tmp_path / "data/stub" / "986428ef9d5a1852fc15d4367f19aa328ad530686056e9d83cdde03407c0bceb" / "My-Stub.zip" ),

freakboy3742 · 2026-02-17T04:26:45Z

tests/commands/upgrade/test_call.py

-    assert capsys.readouterr().out == (
-        "\n"
+    assert (
+        capsys.readouterr().out == "\n"


This is an odd change - the brackets are the exact opposite of what I would have expected. The reasoning is the same as for other bracket usage - it's not intuitive to tell which statements are the start of a string, and which the start of a new argument. The previous formatting made this clear - copses.readouterr().out = (...some multiline string...); the new formatting is ambiguous.

freakboy3742 · 2026-02-17T04:27:36Z

tests/config/test_merge_pep621_config.py


 def test_test_dependencies_without_requires():
-    "If the global config doesn't specify test requirements, test dependencies are used as is"
+    """If the global config doesn't specify test requirements, test " "dependencies are


A stray pair of quotes, probably from a line break that existed at one point:

Suggested change

"""If the global config doesn't specify test requirements, test " "dependencies are

"""If the global config doesn't specify test requirements, test dependencies are

freakboy3742 · 2026-02-17T04:28:35Z

tests/console/Console/test_textwrap.py

+            (
+                "There is nothing wrong with your television set.\n"
+                "Do not attempt to adjust the picture."
+            ),


+1 to this change - this is the preferred format for multi-line strings.

freakboy3742 · 2026-02-17T04:30:23Z

tests/console/Console/test_wait_bar.py

-        "Wait message... started\nWait message... finished\n"
+    assert (
+        capsys.readouterr().out == "Wait message... started\nWait message... finished\n"
    )


This is a bit of a value judgement - if an automated tool is doing this, then fine; but otherwise the older format would be preferred.

freakboy3742 · 2026-02-17T04:31:06Z

tests/console/test_NotDeadYet.py

-        "... still waiting\n... still waiting\n... still waiting\n"
+    assert (
+        capsys.readouterr().out
+        == "... still waiting\n... still waiting\n... still waiting\n"


Again - the older format would be preferred unless this is a tool automated change.

freakboy3742 · 2026-02-28T05:38:11Z

As a procedural thing - can I ask that you don't mark conversations as resolved (or, rather, that you only mark a conversation as resolved if your the person who started the conversation). When I (or another reviewer) provides a comment, that usually means we intend to review later work and ensure that the issues that were found have been resolved - that is when the conversation is resolved. Otherwise, the reviewer loses the context that they asked for a change, and it's not necessarily clear if the way you've responded to the comment was what was the reviewer intended.

Otherwise, it looks like we're 1 pre-commit violation statement away from this being reviewable. If you make that fix, I'll take another pass at it.

JohananOppongAmoateng · 2026-03-04T21:32:30Z

As a procedural thing - can I ask that you don't mark conversations as resolved (or, rather, that you only mark a conversation as resolved if your the person who started the conversation). When I (or another reviewer) provides a comment, that usually means we intend to review later work and ensure that the issues that were found have been resolved - that is when the conversation is resolved. Otherwise, the reviewer loses the context that they asked for a change, and it's not necessarily clear if the way you've responded to the comment was what was the reviewer intended.

Otherwise, it looks like we're 1 pre-commit violation statement away from this being reviewable. If you make that fix, I'll take another pass at it.

okay thanks for letting me know

JohananOppongAmoateng · 2026-03-04T21:34:09Z

@freakboy3742 @kattni sorry this pr has really been slow i have to work on some other stuff since last week hoping i can free up sometime this week and get this over the finish line

freakboy3742

Thanks for those updates. I've pushed a couple of final cleanups; the main issue is around when to use brackets on a multi-line string.

To be clear about the problem I'm referring to: the issue we're trying to avoid is the following:

    some_function(
        "this is a long string"
        "that continues onto multiple lines",
        "but this is a *second* argument, not a third",
    )

This is 100% legal Python, but it's not clear that the first two lines are actually one argument. By adding braces:

    some_function(
        (
            "this is a long string"
            "that continues onto multiple lines"
        ),
        "but this is a *second* argument, not a third",
    )

there's at least a visual cue that the first two string segments are a single argument.

They're both completely legal Python; the preference for the second is purely a code readability thing. Unfortunately, I'm not aware of any way to enforce that rule systematically; and this PR had a number of cases where the "preferred" syntax was reverted.

That's a relatively minor set of changes, though - the rest of your work on this PR is great.

freakboy3742 · 2026-03-05T03:36:10Z

tests/commands/base/test_update_cookiecutter_cache.py

        ),
        pytest.param(
-            "\n stderr: 'Mysterious git clone edge case with no fatal error.",
+            ("\n stderr: 'Mysterious git clone edge case with no fatal error."),


The brackets are redundant here.

Suggested change

("\n stderr: 'Mysterious git clone edge case with no fatal error."),

"\n stderr: 'Mysterious git clone edge case with no fatal error.",

freakboy3742 · 2026-03-05T03:38:29Z

tests/commands/base/test_update_cookiecutter_cache.py

+            "Unable to access 'https://example.com/': OpenSSL/3.2.2: "
+            "error:0A000438:SSL routines::tlsv1 alert internal error.",


Suggested change

"Unable to access 'https://example.com/': OpenSSL/3.2.2: "

"error:0A000438:SSL routines::tlsv1 alert internal error.",

(

"Unable to access 'https://example.com/': OpenSSL/3.2.2: "

"error:0A000438:SSL routines::tlsv1 alert internal error."

),

freakboy3742 · 2026-03-05T03:41:36Z

tests/commands/base/test_update_cookiecutter_cache.py

+            "Could not read from remote repository.\n\nPlease make sure "
+            "you have the correct access rights\nand the repository exists.",


Suggested change

"Could not read from remote repository.\n\nPlease make sure "

"you have the correct access rights\nand the repository exists.",

(

"Could not read from remote repository.\n\nPlease make sure "

"you have the correct access rights\nand the repository exists."

),

freakboy3742 · 2026-03-05T03:42:05Z

tests/commands/create/test_create_app.py

+        (
+            f"The directory {bundle_path.relative_to(base_path)} already exists;"
+            " overwrite"
+            " [y/N]? "
+        ),


Suggested change

(

f"The directory {bundle_path.relative_to(base_path)} already exists;"

" overwrite"

" [y/N]? "

),

(

f"The directory {bundle_path.relative_to(base_path)} already exists;"

" overwrite [y/N]? "

),

freakboy3742 · 2026-03-05T03:42:19Z

tests/commands/create/test_create_app.py

+            " overwrite"
+            " [y/N]? "


Suggested change

" overwrite"

" [y/N]? "

" overwrite [y/N]? "

freakboy3742 · 2026-03-05T03:42:53Z

tests/commands/create/test_create_app.py

+            " overwrite"
+            " [y/N]? "


Suggested change

" overwrite"

" [y/N]? "

" overwrite [y/N]? "

JohananOppongAmoateng added 2 commits February 16, 2026 13:20

fixing e501 for tests/commands

3ec1457

changes

8a2524a

JohananOppongAmoateng marked this pull request as ready for review February 16, 2026 13:34

JohananOppongAmoateng added 3 commits February 16, 2026 14:20

fix e501 for tests/console and tests/config

eeb2212

update

c8da2d3

fix precommit

e637047

JohananOppongAmoateng force-pushed the e501-tests branch from f86ad08 to e637047 Compare February 16, 2026 15:47

freakboy3742 requested changes Feb 17, 2026

View reviewed changes

JohananOppongAmoateng added 3 commits February 17, 2026 20:52

fix

3ed0652

fix

6cd048b

fix

51fdfbf

JohananOppongAmoateng and others added 3 commits March 5, 2026 02:41

fix linting

d82dc34

Merge branch 'main' into e501-tests

8bb8ff0

fix linting

38dd8c5

JohananOppongAmoateng requested a review from freakboy3742 March 5, 2026 03:22

Final touch ups.

719f835

freakboy3742 approved these changes Mar 5, 2026

View reviewed changes

freakboy3742 merged commit 7853cea into beeware:main Mar 5, 2026
60 checks passed

		"\n stderr: '\nfatal: could not clone repository"
		" 'https://example.com' \n'",

		f"The directory {bundle_path.relative_to(base_path)} already exists; overwrite"
		" [y/N]? "

	"""If the global config doesn't specify test requirements, test " "dependencies are
	"""If the global config doesn't specify test requirements, test dependencies are

	("\n stderr: 'Mysterious git clone edge case with no fatal error."),
	"\n stderr: 'Mysterious git clone edge case with no fatal error.",

		"Unable to access 'https://example.com/': OpenSSL/3.2.2: "
		"error:0A000438:SSL routines::tlsv1 alert internal error.",

		"Could not read from remote repository.\n\nPlease make sure "
		"you have the correct access rights\nand the repository exists.",

Uh oh!

Conversation

JohananOppongAmoateng commented Feb 16, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

PR Checklist:

Uh oh!

freakboy3742 left a comment

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

freakboy3742 commented Feb 28, 2026

Uh oh!

JohananOppongAmoateng commented Mar 4, 2026

Uh oh!

JohananOppongAmoateng commented Mar 4, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

freakboy3742 left a comment

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

2 participants

JohananOppongAmoateng commented Feb 16, 2026 •

edited

Loading

JohananOppongAmoateng commented Mar 4, 2026 •

edited

Loading