One issue that I don’t believe was anticipated is around the stdlib ensurepip module. This does not (currently) supply the --break-system-packages flag, and therefore can’t install pip into an externally managed site-packages. This came up in ensurepip has no --break-system-packages option · Issue #118384 · python/cpython · GitHub. Given the expectation that ensurepip is used “for bootstrapping the pip installer into an existing Python installation or virtual environment” I don’t know is that’s reasonable or not. My initial assumption was that if you’re using ensurepip as part of building Python, you’re in control of the site-packages directory and can decide when to mark it as externally managed (and choosing how and when to install pip would be part of that).
What is the PEP authors’ view on this? Should users be running ensurepip on an externally managed site-packages? If they should, is it something we should allow automatically, based on the nature of ensurepip, or should it require an opt-in flag (which would need to be added to ensurepip, and which would likely not be backported to existing Python releases)?