Use install_only_stripped by default in certain cases

[rickeylev]

We added the install_only_stripped runtimes to the default set of runtimes and made using them an opt-in choice with a flag.

Using them by default was brought up, but the discussion fizzled, so it was left as opt-in. For reference, a stripped runtime is about 26MB. Unstripped varies, but the largest is the 3.15 free threaded ones, which are 77MB.

Ignas suggested to have -c opt use install_only_stripped. I'm generally +1 on this.

My main reservation with enabling it by default is that tests benefit from having debug symbols, especially for projects that use a lot of C++ code. If we could use stripped runtimes for binaries, but not tests, when in opt mode, that'd be ideal, I think.

Maybe, at the least, we have py_zipapp default to stripped runtimes when in opt mode? That would help address the originating issue of zipapps being too large.

I'll suggest: enable it for exec mode by default. Exec tools are unlikely to need debug symbols and would benefit from a smaller runtime.

cc @gfrankliu @aignas

[gfrankliu]

+1 to the direction: stripped for exec tools and for opt-mode binaries/zipapps, unstripped for tests.

One clarification on the cost, since "projects that use a lot of C++ code" could read as if stripping affects the project's own C++. It doesn't: install_only_stripped only strips the files in the python-build-standalone archive (the interpreter, libpython, the stdlib's C modules, and bundled libs like Tcl/Tk). A project's own C++ extensions and third-party wheels keep whatever debug info they were built with.

It also only removes the DWARF debug info, not the symbol tables. Comparing 3.12.13 on x86_64-unknown-linux-gnu (sizes are unpacked on disk, not the compressed archive sizes above):

	install_only	install_only_stripped
Unpacked size	344 MB	105 MB
python3.12	symbols + debug info	symbols only
Symbol count (nm)	68,074	68,074

So native backtraces from gdb, sanitizers, perf or core dumps still show CPython function names. And faulthandler still prints the Python traceback on a segfault.

What you do lose is source-level debugging of the interpreter itself: line numbers, locals and stepping in CPython frames, plus gdb's Python helpers (py-bt, py-list), which need the interpreter's debug info. When a test crashes inside a C++ extension, "which Python code called this" is a real need, so keeping tests unstripped makes sense to me.

[rickeylev]

Thanks for clarifying what in the runtime is stripped out. TIL.