Why is the python package so large?

[mistercrunch]

Hey, digging into my docker images, I found that the largest thing I have in there is the playwright bundle, more specifically something located at playwright/driver/node

$ du -h .venv/lib/python3.10/site-packages/playwright/driver/node
118M    .venv/lib/python3.10/site-packages/playwright/driver/node

From my understanding the python bundle comes with a CLI that installs specific bundles when running it, and those install in user space, on demand, at places like /Users/{USER}/Library/Caches/ms-playwright/

So what's in driver/node? Is it really required? Why is it so large?

[mxschmitt]

Playwright language bindings (e.g. Python) talk over a client/server protocol to the Playwright Driver over stdin/out. The driver deals with all the browser communication, retries and logic around it. It is written in Node.js, hence we ship a copy of Node.js in the wheel. So we use it for this and for browser installation/cli interaction.

We once investigated into creating a smaller Node.js binary by e.g. stripping out ICU - we should maybe revisit that.

[mistercrunch]

Gotcha. Wondering if that code could be "minimized", compressed, or bundled differently. Hard to tell as an outsider to the project...

[mxschmitt]

Its the Node.js binary which is large. Unfortunately on macOS binaries tend to be larger compared to Linux. We were exploring in the past building the Node.js version without ICU in order to make it smaller - I can revisit that experiment and get some actual numbers.

[mistercrunch]

Oh interesting - curious on the reason why arm builds might be bigger than amd (?)

[mxschmitt]

amd is similar - its more Linux vs. macOS because of Mach-O vs. ELF