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.
And WebAssembly is definitely not a blocker for this as shown by Make zlib required on all platforms (simplifies code) · Issue #91246 · python/cpython · GitHub , so I think the only blocker on this is someone doing the work.
I suspect that zlib is already effectively required anyways.
If you don’t have zlib the make fails by default (due to ensurepip), and a number of modules (like binascii) rely on zlib being present. I don’t think I’ve seen people guard against those modules being missing in my entire Python programming career.
If your platform supports pip, then yes. 
Feel free to look in the stdlib then as we do in some places for WASI support.
zlib has an as-of-now unresolved critical vulnerability. While that specific vulnerability will get fixed eventually, it’s not the first vulnerability in zlib and probably won’t be the last. It would be nice to maintain the ability to build Python without zlib for such circumstances.
Just for reference, the mentioned vulnerability (CVE-2023-45853) affects the MiniZip ‘contrib’ package, not zlib itself. As noted on the NVD page, NOTE: MiniZip is not a supported part of the zlib product. Python is not affected by it, and most other users of zlib probably aren’t either.
Security vulnerabilities should be assumed inevitable in every dependency (including Python); zlib is not special here.
You need zlib to install pip, as both the wheel and sdist are compressed. The problem is not 300 extra lines of code. It’s that practically, for most users, CPython without zlib is broken.
But,
Let’s make that official. I propose to change our messaging, not (much) code.
Here’s a concrete proposal. Where I say WASI, Android/iOS (or any other platform) can be added if needed.
The 3.14 What’s New should say:
zlibis now officially required to build CPython.
It is still technically possible to build CPython without it for special needs, like bootstrapping. Such builds are not supported, but we can accept pull requests to keep them working.
As an exception,zlibis not required on WASI.
Lib/test/test_zlib.py should add the following comment, and a zlib-less build should fail with an error message that points to it. This serves as a deprecation warning. (On WASI the tests should instead continue to be skipped.)
Building CPython without
zlibis not supported.
Anyone who wants build CPython this way should be prepared to patch it, but the core team may help getting those patches to themainbranch (as that’s the place where multiple third parties can cooperate).For tests to pass without
zlib, this file needs to be removed.
Existing tests skips (e.g. @requires_zlib()) stay in (except in test_zlib.py itself, as above).
binascii’s reimplementation of crc32 is removed; corresponding tests are skipped.
Code that only generates nice error messages in zlib-less builds is removed. Corresponding tests are adjusted.
PEP 11 gets a new entry:
zlib, except WASILib/test/test_zlib.py for details)configure is changed to produce a warning on systems without zlib, except WASI.
Note that the WASI exception means that we’ll still test some zlib-less build. That’s a good thing.
Getting zlib there is the opposite of a blocker issue: I’d prefer that to happen well after this change.
Bootstrapping what? zlib is not written in Python. It is also much smaller and easier to build than CPython, so nothing should be gained by making it optional.
This wording is much too ambiguous IMHO. If they are not supported, why do we make an official claim that they are currently working?
Why not? Does this imply that, for some weird reason, WASI is able to build CPython but not zlib?
Some larger system that builds zlib.
I don’t know of such a system, but rather than proving that one doesn’t exist, I submit a proposal that wouldn’t break it.
We don’t. Whoever builds (and tests) such a build can make that claim.
I can change the sentence to just Such builds are not supported.
No, just that we test without it.
To quote the original motivation:
If what you’re saying @encukou is that we should keep the conditionals everywhere, then there is not much a progress, is it?