macOS bundle ships both arm64 and x86_64 Python code (universal2), bloating single-arch builds

[dpage]

Summary

The macOS app bundle ships both arm64 and x86_64 code in its Python
framework, even though each release is built for (and only runs on) a single
architecture. This bloats the bundle/DMG with a foreign-architecture slice
that is never executed.

Cause

pkg/mac/build-functions.sh builds the embedded Python via
relocatable-python,
which downloads the python.org universal2 installer. As a result the
entire Python.framework (the Python dylib, bin/python3.x, every
lib-dynload/*.so, and compiled site-packages such as cryptography,
bcrypt, psycopg_c, nacl, ...) carries both arm64 and x86_64 slices.
The universal2 installer also drops two stragglers:

• bin/python3.x-intel64 — a pure-x86_64 launcher, and
• lib/python3.x/config-3.x-darwin/python.o — a stray build object.

PostgreSQL-sourced dylibs pulled in via _fixup_imports (libpq, libssl,
libcrypto, ...) may also be universal.

Electron and its helpers are already downloaded single-arch (matching the
build machine), so they are unaffected.

Expected

The bundle should ship only the architecture it is built for. Each
universal/fat Mach-O should have its foreign slice stripped (lipo -thin),
and the arch-specific stragglers removed, before code-signing.

Notes

lipo can only keep a slice that already exists, so this strips the
build machine's foreign slice from an otherwise-correct build; it does not
let an arm64 build produce an x86_64 bundle (or vice versa).