Best practice proposal: do not recommend --system for a Docker context #2762
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
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 utilitieswritten in Python like
add-apt-repository
whose use is widespread inDockerfiles.
By inadvertently applying an application's dependency onto the the container's Python, it is possible to:
docker run|exec ... COMMAND
is used to run another process inside the same container for debugging purposesI 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 termto designate the global Python for that OS/container image.
The checklist
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 #.