The issue

Despite an application's Docker container not usually running other Python processes than the application itself, it still has a system Python whose packages should not necessarily be overwritten or upgraded by an application's choices.

For example, python3-software-properties in Ubuntu contains utilities
written in Python like add-apt-repository whose use is widespread in
Dockerfiles.

By inadvertently applying an application's dependency onto the the container's Python, it is possible to:

• subtly break system-level software like these that is still present in the container image
• run into errors where that software is executed while extending the image with another Dockerfile
• run into errors when docker run|exec ... COMMAND is used to run another process inside the same container for debugging purposes

I realize this is not necessarily a likely use case, but we have seen
enough projects/tools vendoring Requests in fear of a conflict.

The fix

The best practice in my opinion is to favor virtual environments inside a Docker container as the standard use case, as it is for deployment onto a full-fledged OS.

Very open on the wording and whether system Python is the correct term
to designate the global Python for that OS/container image.

The checklist

• The issue itself is captured in this description, as this was a small change to propose (but complex to describe)
• A news fragment in the news/ directory to describe this fix with the extension .bugfix, .feature, .behavior, .doc. .vendor. or .trivial (this will appear in the release changelog). Use semantic line breaks and name the file after the issue number or the PR #.