Skip to content

Commit 72b168b

Browse files
authored
Merge pull request #756 from encukou/pep-627-recording-installed-projects
PEP 627: Recording installed projects
2 parents 29aea30 + c8ce64f commit 72b168b

2 files changed

Lines changed: 173 additions & 8 deletions

File tree

source/specifications/distribution-formats.rst

Lines changed: 2 additions & 0 deletions
Original file line numberDiff line numberDiff line change
@@ -17,6 +17,8 @@ There is also the legacy source distribution format, implicitly defined by
1717
the behaviour of ``distutils`` module in the standard library,
1818
when executing ``setup.py sdist``.
1919

20+
.. _binary-distribution-format:
21+
2022
Binary distribution format
2123
==========================
2224

Lines changed: 171 additions & 8 deletions
Original file line numberDiff line numberDiff line change
@@ -1,12 +1,175 @@
1-
21
.. _recording-installed-packages:
32

4-
=================================
5-
Recording installed distributions
6-
=================================
3+
============================
4+
Recording installed projects
5+
============================
6+
7+
This document specifies a common format of recording information
8+
about Python :term:`projects <Project>` installed in an environment.
9+
A common metadata format allows tools to query, manage or uninstall projects,
10+
regardless of how they were installed.
11+
12+
Almost all information is optional.
13+
This allows tools outside the Python ecosystem, such as Linux package managers,
14+
to integrate with Python tooling as much as possible.
15+
For example, even if an installer cannot easily provide a list of installed
16+
files in a format specific to Python tooling, it should still record the name
17+
and version of the installed project.
18+
19+
20+
History and change workflow
21+
===========================
22+
23+
The metadata described here was first specified in :pep:`376`, and later
24+
ammended in :pep:`627`.
25+
It was formerly known as *Database of Installed Python Distributions*.
26+
Further amendments (except trivial language or typography fixes) must be made
27+
through the PEP process (see :pep:`1`).
28+
29+
While this document is the normative specification, these PEPs that introduce
30+
changes to it may include additional information such as rationales and
31+
backwards compatibility considerations.
32+
33+
34+
The .dist-info directory
35+
========================
36+
37+
Each project installed from a distribution must, in addition to files,
38+
install a "``.dist-info``" directory located alongside importable modules and
39+
packages (commonly, the ``site-packages`` directory).
40+
41+
This directory is named as ``{name}-{version}.dist-info``, with `name` and
42+
`version` fields corresponding to :ref:`core-metadata`.
43+
The name field must be in normalized form (see `PEP 503 <https://www.python.org/dev/peps/pep-0503/#normalized-names>`_
44+
for the definition of normalization).
45+
46+
This ``.dist-info`` directory can contain these files, described in detail
47+
below:
48+
49+
* ``METADATA``: contains project metadata
50+
* ``RECORD``: records the list of installed files.
51+
* ``INSTALLER``: records the name of the tool used to install the project.
52+
53+
The ``METADATA`` file is mandatory.
54+
All other files may be omitted at the installing tool's discretion.
55+
Additional installer-specific files may be present.
56+
57+
.. note::
58+
59+
The :ref:`binary-distribution-format` specification describes additional
60+
files that may appear in the ``.dist-info`` directory of a :term:`Wheel`.
61+
Such files may be copied to the ``.dist-info`` directory of an
62+
installed project.
63+
64+
The previous versions of this specification also specified a ``REQUESTED``
65+
file. This file is now considered a tool-specific extension, but may be
66+
standardized again in the future. See `PEP 376 <https://www.python.org/dev/peps/pep-0376/#requested>`_
67+
for its original meaning.
68+
69+
70+
The METADATA file
71+
=================
72+
73+
The ``METADATA`` file contains metadata as described in the :ref:`core-metadata`
74+
specification, version 1.1 or greater.
75+
76+
The ``METADATA`` file is mandatory.
77+
If it cannot be created, or if required core metadata is not available,
78+
installers must report an error and fail to install the project.
79+
80+
81+
The RECORD file
82+
===============
83+
84+
The ``RECORD`` file holds the list of installed files.
85+
It is a CSV file containing one record (line) per installed file.
86+
87+
The CSV dialect must be readable with the default ``reader`` of Python's
88+
``csv`` module:
89+
90+
* field delimiter: ``,`` (comma),
91+
* quoting char: ``"`` (straight double quote),
92+
* line terminator: either ``\r\n`` or ``\n``.
93+
94+
Each record is composed of three elements: the file's **path**, the **hash**
95+
of the contents, and its **size**.
96+
97+
The *path* may be either absolute, or relative to the directory containing
98+
the ``.dist-info`` directory (commonly, the ``site-packages`` directory).
99+
On Windows, directories may be separated either by forward- or backslashes
100+
(``/`` or ``\``).
101+
102+
The *hash* is either an empty string or the name of a hash algorithm from
103+
``hashlib.algorithms_guaranteed``, followed by the equals character ``=`` and
104+
the digest of the file's contents, encoded with the urlsafe-base64-nopad
105+
encoding (``base64.urlsafe_b64encode(digest)`` with trailing ``=`` removed).
106+
107+
The *size* is either the empty string, or file's size in bytes,
108+
as a base 10 integer.
109+
110+
For any file, either or both of the *hash* and *size* fields may be left empty.
111+
Commonly, entries for ``.pyc`` files and the ``RECORD`` file itself have empty
112+
*hash* and *size*.
113+
For other files, leaving the information out is discouraged, as it
114+
prevents verifying the integrity of the installed project.
115+
116+
If the ``RECORD`` file is present, it must list all installed files of the
117+
project, except ``.pyc`` files corresponding to ``.py`` files listed in
118+
``RECORD``, which are optional.
119+
Notably, the contents of the ``.dist-info`` directory (including the ``RECORD``
120+
file itself) must be listed.
121+
Directories should not be listed.
122+
123+
To completely uninstall a package, a tool needs to remove all
124+
files listed in ``RECORD``, all ``.pyc`` files (of all optimization levels)
125+
corresponding to removed ``.py`` files, and any directories emptied by
126+
the uninstallation.
127+
128+
Here is an example snippet of a possible ``RECORD`` file::
129+
130+
/usr/bin/black,sha256=iFlOnL32lIa-RKk-MDihcbJ37wxmRbE4xk6eVYVTTeU,220
131+
../../../bin/blackd,sha256=lCadt4mcU-B67O1gkQVh7-vsKgLpx6ny1le34Jz6UVo,221
132+
__pycache__/black.cpython-38.pyc,,
133+
__pycache__/blackd.cpython-38.pyc,,
134+
black-19.10b0.dist-info/INSTALLER,sha256=zuuue4knoyJ-UwPPXg8fezS7VCrXJQrAP7zeNuwvFQg,4
135+
black-19.10b0.dist-info/LICENSE,sha256=nAQo8MO0d5hQz1vZbhGqqK_HLUqG1KNiI9erouWNbgA,1080
136+
black-19.10b0.dist-info/METADATA,sha256=UN40nGoVVTSpvLrTBwNsXgZdZIwoKFSrrDDHP6B7-A0,58841
137+
black-19.10b0.dist-info/RECORD,,
138+
black.py,sha256=45IF72OgNfF8WpeNHnxV2QGfbCLubV5Xjl55cI65kYs,140161
139+
blackd.py,sha256=JCxaK4hLkMRwVfZMj8FRpRRYC0172-juKqbN22bISLE,6672
140+
blib2to3/__init__.py,sha256=9_8wL9Scv8_Cs8HJyJHGvx1vwXErsuvlsAqNZLcJQR0,8
141+
blib2to3/__pycache__/__init__.cpython-38.pyc,,
142+
blib2to3/__pycache__/pygram.cpython-38.pyc,sha256=zpXgX4FHDuoeIQKO_v0sRsB-RzQFsuoKoBYvraAdoJw,1512
143+
blib2to3/__pycache__/pytree.cpython-38.pyc,sha256=LYLplXtG578ZjaFeoVuoX8rmxHn-BMAamCOsJMU1b9I,24910
144+
blib2to3/pygram.py,sha256=mXpQPqHcamFwch0RkyJsb92Wd0kUP3TW7d-u9dWhCGY,2085
145+
blib2to3/pytree.py,sha256=RWj3IL4U-Ljhkn4laN0C3p7IRdfvT3aIRjTV-x9hK1c,28530
146+
147+
If the ``RECORD`` file is missing, tools that rely on ``.dist-info`` must not
148+
atempt to uninstall or upgrade the package.
149+
(This does not apply to tools that rely on other sources of information,
150+
such as system package managers in Linux distros.)
151+
152+
153+
The INSTALLER file
154+
==================
155+
156+
If present, ``INSTALLER`` is a single-line text file naming the tool used to
157+
install the project.
158+
If the installer is executable from the command line, ``INSTALLER``
159+
should contain the command name.
160+
Otherwise, it should contain a printable ASCII string.
161+
162+
The file can be terminated by zero or more ASCII whitespace characters.
163+
164+
Here are examples of two possible ``INSTALLER`` files::
165+
166+
pip
167+
168+
::
7169

8-
The format used to record installed packages and their contents is defined in
9-
:pep:`376`.
170+
MegaCorp Cloud Install-O-Matic
10171

11-
Note that only the ``dist-info`` directory and the ``RECORD`` file format from
12-
that PEP are currently implemented in the default packaging toolchain.
172+
This value should be used for informational purposes only.
173+
For example, if a tool is asked to uninstall a project but finds no ``RECORD``
174+
file, it may suggest that the tool named in ``INSTALLER`` may be able to do the
175+
uninstallation.

0 commit comments

Comments
 (0)