Distutils compatibility boundary in Python 3.12 deployment builds

Python 3.12 removed the long-deprecated distutils package from the standard library, shifting any deployment or build script that imports distutils directly onto a replacement. Setuptools provides a vendored distutils through its _distutils_hack, but that shim activates only when setuptools is imported first. The result is an unresolved compatibility boundary: the success of import distutils depends on import order and whether setuptools is present in the environment, rather than on a stable API contract.

This boundary creates practical uncertainty for deployments that must run across development and production images. A build may succeed locally where setuptools is pre-installed, yet fail in a minimal container that lacks it. Legacy packages may also rely on deprecated or platform-specific distutils behaviors that the vendored copy does not reproduce, and manually vendoring or patching distutils introduces maintenance debt that can conflict with future setuptools or Python releases.

Given these constraints, what is the safest way to handle distutils-dependent builds during the Python 3.12 transition without relying on import-order side effects? Should teams pin setuptools explicitly in deployment images, or is a direct migration to setuptools, sysconfig, and importlib.metadata the only supported path for legacy packages? How can teams verify that a vendored distutils shim preserves the specific behaviors their build requires before deploying?