upgrading to pytest 8.3.5 causes :Cannot read termcap database;using dumb terminal settings" error

[KRRT7]

for whatever reason, upgrading to pytest 8.3.5 causes our CI to fail due to Cannot read termcap database;\nusing dumb terminal settings.\n

but downgrading to 8.3.4 fixes it

https://github.com/codeflash-ai/codeflash/actions/runs/13642372967/job/38135678334
here's it failing
here's it passing: https://github.com/codeflash-ai/codeflash/actions/runs/13642928960/job/38136415503?pr=24
happening on 3.11 & 3.12

reported initially on discord

[The-Compiler]

My best bet would be #13176, given the error message. Can you try putting import readline somewhere where your execute_test_subprocess can pick it up (maybe a conftest.py?) and see if you get the same behavior with 8.3.4 then? If so, you'll probably need to find out what's special about your environment/Python/CI that makes import readline fail in that way.

[Zac-HD]

Hmm, looking at #13176, there's a long history of problems here. It might be worth trying some automated diagnostics when we encounter similar issues, so we can give a more detailed error message and if possible suggest a fix?

(inspired by HypothesisWorks/hypothesis#3472, which I admit was complete overkill but did solve the problem)

[The-Compiler]

Hmm yeah. We could import readline in a subprocess, which would also let us check for various scenarios:

1. It's a libedit readline but could get imported successfully -> apply the workaround by also importing it in the main process
2. It's a GNU readline but could get imported successfully -> don't apply the workaround
3. ModuleNotFoundError (Windows) -> don't apply the workaround
4. Any other ImportError -> broken setup, maybe silently do nothing, maybe warn (we can't figure out if it needs the workaround or not)
5. Wrote stuff to sys.stderr on import (like seems to be the case here) -> broken setup... silently do nothing? warn? Either of the two depending on whether it's a readline that would need the workaround or not?

Not sure if I like the idea. It sounds like something that potentially comes with more subtle ways for things to break, plus it increases the startup time for everyone (by what might or might not be a significant amount).

[RonnyPfannschmidt]

This might be something to move to a package to share code with other projects

It may be valid to add a python -m based cli to query and/or cache plus a python api on top

[github-actions]

This issue is stale because it has the status: needs information label and requested follow-up information was not provided for 14 days.

[github-actions]

This issue was closed because it has the status: needs information label and follow-up information has not been provided for 7 days since being marked as stale.

[jwarlander]

I'm also experiencing the same problem, even running locally.

Here's a quick way to set up a project that should be affected by this issue:

❯ uv version
uv 0.6.12

❯ uv init hello
Initialized project `hello` at `/home/johan/src/hello`

❯ cd hello/

❯ cat > test.py
def func(x):                                   
    return x + 1

def test_answer():
    assert func(3) == 5

Running pytest with latest version (8.3.5) now generates the warning message:

❯ uv add --dev pytest
Using CPython 3.12.1
Creating virtual environment at: .venv
Resolved 6 packages in 152ms
Prepared 4 packages in 99ms
Installed 4 packages in 7ms
 + iniconfig==2.1.0
 + packaging==24.2
 + pluggy==1.5.0
 + pytest==8.3.5

❯ uv run pytest *.py
Cannot read termcap database;
using dumb terminal settings.
======================================== test session starts ========================================
platform linux -- Python 3.12.1, pytest-8.3.5, pluggy-1.5.0
rootdir: /home/johan/src/hello
configfile: pyproject.toml
collected 1 item                                                                                    

test.py F                                                                                     [100%]

============================================= FAILURES ==============================================
____________________________________________ test_answer ____________________________________________

    def test_answer():
>       assert func(3) == 5
E       assert 4 == 5
E        +  where 4 = func(3)

test.py:6: AssertionError
====================================== short test summary info ======================================
FAILED test.py::test_answer - assert 4 == 5
========================================= 1 failed in 0.01s =========================================

If I switch to 3.8.4, it's fine:

❯ uv add --dev pytest==8.3.4
Resolved 6 packages in 54ms
Prepared 1 package in 101ms
Uninstalled 1 package in 6ms
Installed 1 package in 9ms
 - pytest==8.3.5
 + pytest==8.3.4

❯ uv run pytest *.py
======================================== test session starts ========================================
platform linux -- Python 3.12.1, pytest-8.3.4, pluggy-1.5.0
rootdir: /home/johan/src/hello
configfile: pyproject.toml
collected 1 item                                                                                    

test.py F                                                                                     [100%]

============================================= FAILURES ==============================================
____________________________________________ test_answer ____________________________________________

    def test_answer():
>       assert func(3) == 5
E       assert 4 == 5
E        +  where 4 = func(3)

test.py:6: AssertionError
====================================== short test summary info ======================================
FAILED test.py::test_answer - assert 4 == 5
========================================= 1 failed in 0.02s =========================================

[The-Compiler]

Your reproducer works fine here. As already said above, at its roots this is some sort of misconfiguration on your system, and a python -c "import readline" will most likely trigger the same warning.

[jwarlander]

Hmm yeah it didn't when I tested.. but then I noticed that uv seems to have picked a managed Python 3.12.1 installation by default, where I do indeed get the error.. whereas for 3.12.9, I don't:

❯ uv run --managed-python --python 3.12.1 python -c "import readline"
Cannot read termcap database;
using dumb terminal settings.

~ 
❯ uv run --managed-python --python 3.12.9 python -c "import readline"

~ 

This seems to be due to differences between the build environment and the environment where one happens to run a downloaded Python build:
astral-sh/python-build-standalone#125

After reading about the mentioned quirks, I found out that apparently builds generated after 2024-01-07 have some updated settings so that the issue should be less common.