mirror of
https://github.com/kennethreitz/pipenv.git
synced 2026-06-05 22:50:18 +00:00
Giorgio Sironi
45b5e7d789
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](https://github.com/search?l=Dockerfile&q=%22add-apt-repository%22&type=Code). 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. Very open on the wording and whether `system Python` is the correct term to designate the global Python for that OS/container image.