Consider adopting an image-format-per-plugin model

Pillow's current model of all image formats in one package means that Pillow's footprint will inevitably grow boundlessly. The 10.1.0 Linux wheels were ~3.5MB, 10.2.0 went up to 4.5MB then 11.3.0 jumped all the way up to ~6.5MB for AVIF support (and these are compressed sizes – the installed footprint is worse). For anyone not using the new image formats and where a small footprint is coveted (serverless lambdas, small end user applications, services shipped as Docker images), every new addition is also a large regression.

From a security perspective, a new unneeded format is also a choice between an increased surface area of attack or squatting on old versions of Pillow – both of which are obviously bad. (Being able to limit formats using Image.open(untrusted_content, formats=["JPEG", "PNG"]) helps but it's not really enough that I'd feel comfortable ignoring a CVE in libavif.)

I'm aware that pillow can be built without support for some formats by building from source or just by deleting bits of the package post-install but neither are appealing options and they both get much worse if you want all the files on a server to come from say RPMs for better efficiency and security auditing.

I was using the pillow-avif-plugin in one of my projects for a while before it got merged into pillow. I thought it was a really good model. Anyone who didn't need AVIF support didn't have to pay for its large footprint and anyone who did only had to add one import pillow_avif and an extra item to their dependencies to get it. The integration felt very seamless.

Would you consider adopting a policy whereby all new and/or large and/or niche and/or complex formats are permanently kept as separately distributed pillow_$format_plugin wheels rather than merged into pillow itself?

Begin by comparing Pillow's current all-in-one distribution with the previously used pillow-avif-plugin model, including the stated footprint and security concerns. Done would require a maintainer decision on whether and how to adopt a separate-plugin policy; this issue names no files or tests.