Repository navigation
bin/python size exploded 2000 times larger #3534
Description
Is there a reason why the binary bin/python3.10 in latest python 3.10.19 has size 43963640 which is more than 2000 times larger than bin/python3.10 in python 3.10.15 (size 20944)?
python = use_extension("@rules_python//python/extensions:python.bzl", "python")
python.toolchain(
is_default = True,
python_version = "3.10.15",
)
Activity
shayanhoshyari commentedon Jan 23, 2026
I saw something similar that 3.12 bundle on macos ~10MB is much smaller than linux ~100MB.
aignas commentedon Jan 23, 2026
These are questions to the upstream project https://github.com/astral-sh/python-build-standalone/releases
We do not repackage anything and we are not testing for the size of the interpreter.
gfrankliu commentedon Jan 23, 2026
Maybe we should re-open this.
Based on upstream ticket, they now statically link the libpython into the python binary, so the binary is much bigger. This also means the libpython is no longer needed unless rule_python needs the lib for something else. The above ticket suggested distributions (such as "rules_python") could remove the libpython and that should reduce the total size same as before.
aignas commentedon Jan 23, 2026
Reopening for discussion/planning and implementing, thank you for the reference.
rickeylev commentedon Jan 24, 2026
Thanks for bringing this up. It's nice to have a concrete reason to look at the runtime size of the Python runtime. There's many things in the python runtime that many apps probably don't need at runtime (bundled pip and headers come to mind; within Google we strip more out by default).
There's two something elses:
(1) If a C extension is being built: it needs libpython to link against. This is a build-time only need.
(2) If something is dynamically linking at runtime, e.g. an embedded python C program, then it needs libpython at runtime.
In either case, libpython has to stick around in the extracted repo. That doesn't mean it has to go into the runfiles, though.
The issue, though, is, given an arbitrary binary, we don't know what it needs from the Python runtime it needs at runtime.
I'm +1 on breaking up the glob for the runtime files into some separate targets, and having flags and/or PyRuntime fields carry them.
fix(zipapp): reduce bundled interpreter size (bazel-contrib#4165)
fix(zipapp): reduce bundled interpreter size (#4165)