PEP 668 – Marking Python base environments as “externally managed” | peps.python.org
Following system colour scheme
Selected dark colour scheme
Selected light colour scheme
PEP 668 – Marking Python base environments as “externally managed”
PEP 668 – Marking Python base environments as “externally managed”
Author:<br>Geoffrey Thomas ,<br>Matthias Klose ,<br>Filipe Laíns ,<br>Donald Stufft ,<br>Tzu-ping Chung ,<br>Stefano Rivera ,<br>Elana Hashman ,<br>Pradyun Gedam<br>PEP-Delegate:<br>Paul Moore<br>Discussions-To:<br>Discourse thread<br>Status:<br>Accepted<br>Type:<br>Standards Track<br>Topic:<br>Packaging<br>Created:<br>18-May-2021<br>Post-History:<br>28-May-2021<br>Resolution:<br>Discourse message
Table of Contents<br>Abstract
Terminology
Motivation
Rationale<br>Use cases
Specification<br>Marking an interpreter as using an external package manager
Writing to only the target sysconfig scheme
Recommendations for distros<br>Mark the installation as externally managed
Guide users towards virtual environments
Keep the marker file in container images
Create separate distro and local directories
Backwards Compatibility
Security Implications
Alternatives<br>Marker file
System Python
Implementation Notes
References
Copyright
Important
This PEP is a historical document. The up-to-date, canonical spec, Externally Managed Environments, is maintained on the PyPA specs page.
See the PyPA specification update process for how to propose changes.
Abstract
A long-standing practical problem for Python users has been conflicts<br>between OS package managers and Python-specific package management<br>tools like pip. These conflicts include both Python-level API<br>incompatibilities and conflicts over file ownership.
Historically, Python-specific package management tools have defaulted<br>to installing packages into an implicit global context. With the<br>standardization and popularity of virtual environments, a better<br>solution for most (but not all) use cases is to use Python-specific<br>package management tools only within a virtual environment.
This PEP proposes a mechanism for a Python installation to communicate<br>to tools like pip that its global package installation context is<br>managed by some means external to Python, such as an OS package<br>manager. It specifies that Python-specific package management tools<br>should neither install nor remove packages into the interpreter’s<br>global context, by default, and should instead guide the end user<br>towards using a virtual environment.
It also standardizes an interpretation of the sysconfig schemes so<br>that, if a Python-specific package manager is about to install a<br>package in an interpreter-wide context, it can do so in a manner that<br>will avoid conflicting with the external package manager and reduces<br>the risk of breaking software shipped by the external package manager.
Terminology
A few terms used in this PEP have multiple meanings in the contexts<br>that it spans. For clarity, this PEP uses the following terms in<br>specific ways:
distroShort for “distribution,” a collection of various sorts of<br>software, ideally designed to work properly together, including<br>(in contexts relevant to this document) the Python interpreter<br>itself, software written in Python, and software written in other<br>languages. That is, this is the sense used in phrases such as<br>“Linux distro” or “Berkeley Software Distribution.”A distro can be an operating system (OS) of its own, such as<br>Debian, Fedora, or FreeBSD. It can also be an overlay distribution<br>that installs on top of an existing OS, such as Homebrew or<br>MacPorts.
This document uses the short term “distro,” because the term<br>“distribution” has another meaning in Python packaging contexts: a<br>source or binary distribution package of a single piece of Python<br>language software, that is, in the sense of<br>setuptools.dist.Distribution or “sdist”. To avoid confusion,<br>this document does not use the plain term “distribution” at all.<br>In the Python packaging sense, it uses the full phrase<br>“distribution package” or just “package” (see below).
The provider of a distro - the team or company that collects and<br>publishes the software and makes any needed modifications - is its<br>distributor .
packageA unit of software that can be installed and used within Python.<br>That is, this refers to what Python-specific packaging tools tend<br>to call a “distribution package” or simply a “distribution”;<br>the colloquial abbreviation “package” is used in the sense of the<br>Python Package Index.This document does not use “package” in the sense of an importable<br>name that contains Python modules, though in many cases, a<br>distribution package consists of a single importable package of<br>the same name.
This document generally does not use the term “package” to refer<br>to units of installation by a distro’s package manager (such as<br>.deb or .rpm files). When needed, it uses phrasing such as<br>“a distro’s package.” (Again, in many cases, a Python package is<br>shipped inside a distro’s package named something like python-<br>plus the Python package name.)
Python-specific package managerA...