TL;DR: Python 3.12 removed distutils, and packages built a decade ago stopped installing — usually discovered only when a clean environment fails in production. PainHunt's data shows developers want this caught earlier. The wedge is a breakage monitor plus migration scanner for legacy dependencies.
The evidence
PainHunt's DevTools category holds 1,428 high-commercial-potential posts (10+/15) at an average pain intensity of 7.4/10, with the signal spread across Mastodon, BlueSky, Medium, Discourse and Dev.to.
One cluster is precise. Python 3.12 silently removed the distutils module, breaking packages that were built ten years ago. There is no automated monitoring of install logs for old packages, so the breakage goes undetected until a production failure. The official path — migrating to setuptools — provides behavior that is described as "not identical," which forces code rewrites rather than a clean swap. Maintainers report burning significant time migrating legacy build code, and packages that once shipped "batteries included" now require external dependencies for basic packaging.
Why this exists now
The deprecation was announced years in advance, but deprecation warnings are easy to ignore until the module is actually gone. Removal in 3.12 turned a soft warning into a hard failure, and the long tail of older packages — internal tools, abandoned-but-depended-on libraries, scientific code — never got migrated. The failure surfaces at the worst time: in a fresh CI runner or a production rebuild, far from the developer who could fix it quickly.
The wedge
Catch the breakage before the interpreter upgrade does:
- Install-log monitoring: watch build and install logs across environments for removed-stdlib imports (distutils first) and surface them as alerts, not buried tracebacks.
- Migration scanner: scan a codebase or dependency tree for distutils usage and other 3.12+ removals, and produce a concrete setuptools migration checklist per package.
- Compatibility shim: ship a drop-in distutils shim for teams that need to keep old packages running while they migrate on their own timeline.
The promise: "know which dependencies will break on the next Python upgrade — before it ships."
Risks and honest caveats
- Free alternatives exist: setuptools provides a partial compatibility path, and some shims are already floating around. The product has to be meaningfully better at detection and guidance, not just another shim.
- Narrow trigger, broad pattern: distutils is one removal; the durable product is a general "stdlib and dependency removal" monitor that stays useful across future Python releases.
- Sold to maintainers, paid by teams: individual maintainers feel the pain but rarely pay; the buyer is the team or platform that owns the production rebuild.
How to validate this further
Read the firsthand developer reports in the Pain Point Browser, then size demand with how to validate a startup idea. Related reading: the case for an internal developer platform and a safety net for AI coding tools. Score the strongest clusters in the validator.