python / python/cpython

Strange new line behavior and missing color in the iOS testbed logs

オープン
#150,932 コメント 10 件 リアクション 0 件 担当者 0 名 GitHub で見る

まだ誰も着手していません。

OS-ios OS-mac type-bug
主要言語
Python
スター
77.2k
フォーク
35.9k
PR マージ指標
PR 指標を取得中

説明

Bug report

Bug description:

When using cibuildwheel to build and test a Python package for iOS, pytest output captured through the Apple testbed runner is difficult to read. Two distinct problems occur simultaneously:

1. Progress output is split across individual lines.

pytest emits progress characters (., F, E, s, …) without a trailing newline and flushes after each one. In the captured log each character appears on its own line instead of forming a compact progress line:

============================= test session starts ==============================
 platform ios -- Python 3.13.11, pytest-9.0.3, pluggy-1.6.0
 rootdir: /Users/timrid/Library/Developer/CoreSimulator/Devices/84EFB4EB-1C63-49FF-972C-D7276CB71115/data/Containers/Bundle/Application/3CA6642E-C9F4-4388-B444-2FA31C2AA074/iOSTestbed.app/app
 configfile: setup.cfg
 testpaths: tests/
 plugins: mock-3.15.1, cov-7.1.0, timeout-2.4.0, asyncio-1.4.0
 timeout: 120.0s
 timeout method: signal
 timeout func_only: False
 asyncio: mode=Mode.AUTO, debug=False, asyncio_default_fixture_loop_scope=None, asyncio_default_test_loop_scope=function
 collected 4612 items / 24 deselected / 14 skipped / 4588 selected
 
 tests/test_base_protocol.py
 .
 .
 .
 .
 .
 .
 .
 .
                           [  0%]
                      [  0%]
 
 tests/test_circular_imports.py
 s
 s
 s
 s
 s [  1%]
 s
 s
 s
 s
 s
                                                             [  1%]
 
 tests/test_classbasedview.py
 .
 .
 .
 .
                                         [  1%]
 
...

The same problem affects any output that is deliberately written without a newline — e.g. print(".", end="", flush=True).

2. ANSI color codes are shown as raw escape sequences.

When color is explicitly enabled in pytest via --color=yes, pytest's colored output is not rendered. Instead, raw escape sequences appear as unreadable caret-encoded text:

\^[[1m============================= test session starts ==============================\^[[0m
 platform ios -- Python 3.13.11, pytest-9.0.3, pluggy-1.6.0
 rootdir: /Users/timrid/Library/Developer/CoreSimulator/Devices/84EFB4EB-1C63-49FF-972C-D7276CB71115/data/Containers/Bundle/Application/F9002FB8-67E9-4424-AC42-8F5807D4DB47/iOSTestbed.app/app
 configfile: setup.cfg
 testpaths: tests/
 plugins: mock-3.15.1, cov-7.1.0, timeout-2.4.0, asyncio-1.4.0
 timeout: 120.0s
 timeout method: signal
 timeout func_only: False
 asyncio: mode=Mode.AUTO, debug=False, asyncio_default_fixture_loop_scope=None, asyncio_default_test_loop_scope=function
 collected 4612 items / 24 deselected / 14 skipped / 4588 selected
 
 tests/test_base_protocol.py
 \^[[32m.\^[[0m
 \^[[32m.\^[[0m
 \^[[32m.\^[[0m
 \^[[32m.\^[[0m
 \^[[32m.\^[[0m
 \^[[32m.\^[[0m
 \^[[32m.\^[[0m
 \^[[32m.\^[[0m
 \^[[32m.\^[[0m
 \^[[32m.\^[[0m
 \^[[32m.\^[[0m
 \^[[32m.\^[[0m
 \^[[32m.\^[[0m
 \^[[32m.\^[[0m
 \^[[32m.\^[[0m
 \^[[32m.\^[[0m
 \^[[32m.\^[[0m
 \^[[32m.\^[[0m
 \^[[32m.\^[[0m
 \^[[32m                          [  0%]\^[[0m
 
 tests/test_circular_imports.py
 \^[[33ms\^[[0m
 \^[[33ms\^[[0m
...

Together these two issues make it very hard to interpret test results, especially in CI in combination with bad Github Actions performance on huge test outputs.

I think that this is an upstream CPython issue because the root cause is in Python's Apple system-logger redirection (Lib/_apple_support.py), which is used by the testbed runner to capture output from iOS builds.

Maybe a possible solution for problem 1 is to modify the Apple system-logger redirection in Lib/_apple_support.py to append a marker byte (e.g. 0x1f, ASCII Unit Separator) to any log message that does not end with \n. The testbed runner can then detect the marker, suppress the line break, and join the message with the next one. This would fix it without buffering output or breaking the flush() contract. To solve problem 2, the testbed runner can reverse the system log's caret encoding (\^[ etc.) back into the original control characters, restoring colored output.

@freakboy3742 What do you think?

CPython versions tested on:

3.13

Operating systems tested on:

Other

Linked PRs
  • gh-150983

コントリビューションガイド

コントリビューションガイドを開く

はじめの一歩

  1. issue を最後まで読み、次にプロジェクトのコントリビューションガイドを読みます。
  2. 着手することを issue にコメントします — 二人が同じ作業をするのを防げます。
  3. リポジトリをフォークし、ブランチを切って変更します。
  4. issue 番号を参照したプルリクエストを送ります。

調査の方向性

Lib/_apple_support.py と Apple テストベッド runner から始め、次に --color=yes と改行なしの print を使って pytest の出力を再現します。取得したログを、期待されるコンパクトな進捗出力およびレンダリングされた ANSI カラーと比較します。作業がすでに進行中の可能性があるため、開始前にリンクされた PR gh-150983 を確認してください。

索引モデルが issue の本文から書いたものです。

評価

技術スタック
ios, python
領域
mobile-dev, testing-qa
issue の種類
バグ
難易度
4/5
見積もり時間
3〜5日
活発さ
停滞
明瞭さ
おおむね明確
初心者へのやさしさ
35/100

新しい issue をメールで受け取る

初心者向けの GitHub issue を短くまとめたダイジェスト。