termcap warnings from uv python

[jyoung8607]

Describe the bug

For some time now we've had annoying termcap warnings from scons, pytest, etc. Today it annoyed me enough to track it down. It traces back to the Python build we're using.

(openpilot) jyoung@jy-workstation-ubuntu:~/openpilot$ strace python
...
stat("/home/jyoung/.terminfo", 0x197f3880) = -1 ENOENT (No such file or directory)
stat("/tools/deps/share/terminfo", 0x197f3880) = -1 ENOENT (No such file or directory)
write(2, "Cannot read termcap database;\n", 30Cannot read termcap database;) = 30
write(2, "using dumb terminal settings.\n", 30using dumb terminal settings.) = 30
...

The UV build of Python just doesn't seem to know where Ubuntu's terminfo database lives. Telling it manually with export TERMINFO=/usr/share/terminfo is sufficient to work around the issue.

That said, this is the second time we've been bitten by weirdness in the UV Python build. Are we getting value from it other than being a downloadable pre-built copy of the particular version we want?

Provide a route where the issue occurs

N/A

openpilot version

master

Additional info

No response

[adeebshihadeh]

Interesting find.

In general, I trust that the Astral stuff to be the best to use in the Python ecosystem going forward, but the response to that issue is disappointing. astral-sh/python-build-standalone#125

[jyoung8607]

In general, I trust that the Astral stuff to be the best to use in the Python ecosystem going forward, but the response to that issue is disappointing. astral-sh/python-build-standalone#125

TL;DR: It's been resolved for awhile, we can just bump our way out of it.

The diff in astral-sh/python-build-standalone#625 shows some evolution in the quirk over time:

Starting in the first release after 20240107, the Linux distributions are
configured to automatically use the terminfo database in ``/etc/terminfo``,
``/lib/terminfo``, and ``/usr/share/terminfo``.

On my workstation, UV is choosing the Astral build of 3.12.0. I tested with the Astral build of 3.12.11 and it seems to be fixed. The upstream release dates definitely straddle that 20240107 boundary. So they're not rebuilding the older patch levels with the fix.

I'm not sure how UV chose 3.12.0 for me; Python 3.12.5 was out by the time my workstation was built. openpilot allows any 3.12 patchlevel, opendbc is even looser.

So the correct solution is a patchlevel bump, but I haven't explored how that affects CI or other existing environments.

[adeebshihadeh]

Should be good now with our new uv-managed python build!