Does anyone have strong objections to this? It simplifies our codebase to get rid of the conditionals and extra code we carry for builds in the absence of zlib. The Windows build has treated it as required since forever. The zlib is always available on every supported platform otherwise given how fundamental it is.
Tracked in Make zlib required on all platforms (simplifies code) · Issue #91246 · python/cpython · GitHub with a draft PR demonstrating the cleanup.
The PR drops 300 lines of code.
FWICS Gentoo has always enabled zlib, so no opposition here. I can imagine quite a few things unexpectedly breaking should someone build Python without zlib.
It seems to mostly be a hold over from the post-autoconf 90s when building on unix systems without third party libraries available. I assume the only way it happens now is likely accidental: When someone trys to build python and hasn’t installed their distro’s -dev headers for the common libraries they already have installed. We don’t need to support that.
In Nixpkgs python3 is a relatively early needed package for bootstrapping, however, zlib already seems to be included then so it should be fine.
+1. zlib is ubiquitous nowadays.
Note that in this could enable, the future, things like compressed .pyc files.
WebAssembly builds doesn’t have it yet, but it should be doable with the right amount of time and effort (according to No zlib in WASI · Issue #93819 · python/cpython · GitHub).
One thing to keep in mind here is that requiring zlib means we’re also requiring that zlib be buildable without Python. Considering how fundamental zlib is, and how simple its build is, this is probably fine… but it does make it potentially harder to bootstrap new systems, especially ones that rely on Python for its build system.
You certainly would like to use something more efficient than zlib for that.
Is the expectation that the platform provide the zlib code, or would we ship it for any platform that lacks it?
We’d ship zlib for any platform that lacks it, as we already do for Windows.
In that case I don’t see WebAssembly being a blocker here as it would just be another extension module that got statically linked in.