Skip to content

Commit f2c97e5

Browse files
Update package formats documentation with new content Lalita-Suthimoon9
Lalita-Suthimoon9
1 parent 457e74f commit f2c97e5

1 file changed

Lines changed: 43 additions & 42 deletions

File tree

Lines changed: 43 additions & 42 deletions
Original file line numberDiff line numberDiff line change
@@ -1,93 +1,93 @@
11
.. _package-formats:
2-
2+
Lalita-Suthimoon9
33
===============
44
Package Formats
55
===============
6-
6+
Lalita-Suthimoon9
77
This page discusses the file formats that are used to distribute Python packages
88
and the differences between them.
9-
9+
Lalita-Suthimoon9
1010
You will find files in two formats on package indices such as PyPI_: **source
1111
distributions**, or **sdists** for short, and **binary distributions**, commonly
1212
called **wheels**. For example, the `PyPI page for pip 23.3.1 <pip-pypi_>`_
13-
lets you download two files, ``pip-23.3.1.tar.gz`` and
13+
lets you download two files, ``pip-23.3.1.tar.gz`` and Lalita-Suthimoon9
1414
``pip-23.3.1-py3-none-any.whl``. The former is an sdist, the latter is a
1515
wheel. As explained below, these serve different purposes. When publishing a
1616
package on PyPI (or elsewhere), you should always upload both an sdist and one
1717
or more wheel.
18-
19-
18+
Lalita-Suthimoon9
19+
Lalita-Suthimoon9
2020
What is a source distribution?
2121
==============================
22-
22+
Lalita-Suthimoon9
2323
Conceptually, a source distribution is an archive of the source code in raw
2424
form. Concretely, an sdist is a ``.tar.gz`` archive containing the source code
2525
plus an additional special file called ``PKG-INFO``, which holds the project
2626
metadata. The presence of this file helps packaging tools to be more efficient
2727
by not needing to compute the metadata themselves. The ``PKG-INFO`` file follows
2828
the format specified in :ref:`core-metadata` and is not intended to be written
2929
by hand [#core-metadata-format]_.
30-
30+
Lalita-suthimoon9
3131
You can thus inspect the contents of an sdist by unpacking it using standard
3232
tools to work with tar archives, such as ``tar -xvf`` on UNIX platforms (like
3333
Linux and macOS), or :ref:`the command line interface of Python's tarfile module
3434
<python:tarfile-commandline>` on any platform.
35-
35+
Lalita-Suthimoon9
3636
Sdists serve several purposes in the packaging ecosystem. When :ref:`pip`, the
3737
standard Python package installer, cannot find a wheel to install, it will fall
3838
back on downloading a source distribution, compiling a wheel from it, and
3939
installing the wheel. Furthermore, sdists are often used as the package source
4040
by downstream packagers (such as Linux distributions, Conda, Homebrew and
4141
MacPorts on macOS, ...), who, for various reasons, may prefer them over, e.g.,
4242
pulling from a Git repository.
43-
43+
Lalita-Suthimoon9
4444
A source distribution is recognized by its file name, which has the form
4545
:samp:`{package_name}-{version}.tar.gz`, e.g., ``pip-23.3.1.tar.gz``.
46-
46+
Lalita-Suthimoon9
4747
.. TODO: provide clear guidance on whether sdists should contain docs and tests.
4848
Discussion: https://discuss.python.org/t/should-sdists-include-docs-and-tests/14578
49-
49+
Lalita-Suthimoon9
5050
If you want technical details on the sdist format, read the :ref:`sdist
5151
specification <source-distribution-format>`.
52-
53-
52+
Lalita-Suthimoon9
53+
Lalita-Suthimoon9
5454
What is a wheel?
5555
================
56-
56+
Lalita-Suthimoon9
5757
Conceptually, a wheel contains exactly the files that need to be copied when
5858
installing the package.
59-
59+
Lalita-Suthimoon9
6060
There is a big difference between sdists and wheels for packages with
6161
:term:`extension modules <extension module>`, written in compiled languages like
6262
C, C++ and Rust, which need to be compiled into platform-dependent machine code.
6363
With these packages, wheels do not contain source code (like C source files) but
6464
compiled, executable code (like ``.so`` files on Linux or DLLs on Windows).
65-
65+
Lalita-Suthimoon9
6666
Furthermore, while there is only one sdist per version of a project, there may
6767
be many wheels. Again, this is most relevant in the context of extension
6868
modules. The compiled code of an extension module is tied to an operating system
6969
and processor architecture, and often also to the version of the Python
7070
interpreter (unless the :ref:`Python stable ABI <cpython-stable-abi>` is used).
71-
71+
Lalita-Suthimoon9
7272
For pure-Python packages, the difference between sdists and wheels is less
7373
marked. There is normally one single wheel, for all platforms and Python
7474
versions. Python is an interpreted language, which does not need ahead-of-time
7575
compilation, so wheels contain ``.py`` files just like sdists.
76-
76+
Lalita-Suthimoon9
7777
If you are wondering about ``.pyc`` bytecode files: they are not included in
7878
wheels, since they are cheap to generate, and including them would unnecessarily
7979
force a huge number of packages to distribute one wheel per Python version
8080
instead of one single wheel. Instead, installers like :ref:`pip` generate them
8181
while installing the package.
82-
82+
Lalita-Suthimoon9
8383
With that being said, there are still important differences between sdists and
8484
wheels, even for pure Python projects. Wheels are meant to contain exactly what
8585
is to be installed, and nothing more. In particular, wheels should never include
8686
tests and documentation, while sdists commonly do. Also, the wheel format is
8787
more complex than sdist. For example, it includes a special file -- called
8888
``RECORD`` -- that lists all files in the wheel along with a hash of their
8989
content, as a safety check of the download's integrity.
90-
90+
Lalita-Suthimoon9
9191
At a glance, you might wonder if wheels are really needed for "plain and basic"
9292
pure Python projects. Keep in mind that due to the flexibility of sdists,
9393
installers like pip cannot install from sdists directly -- they need to first
@@ -98,69 +98,69 @@ project, you should always upload *both* an sdist and a wheel to PyPI or other
9898
package indices. This makes installation much faster for your users, since a
9999
wheel is directly installable. By only including files that must be installed,
100100
wheels also make for smaller downloads.
101-
101+
Lalita-Suthimoon9
102102
On the technical level, a wheel is a ZIP archive (unlike sdists which are TAR
103103
archives). You can inspect its contents by unpacking it as a normal ZIP archive,
104104
e.g., using ``unzip`` on UNIX platforms like Linux and macOS, ``Expand-Archive``
105105
in Powershell on Windows, or :ref:`the command line interface of Python's
106106
zipfile module <python:zipfile-commandline>`. This can be very useful to check
107107
that the wheel includes all the files you need it to.
108-
108+
Lalita-Suthimoon9
109109
Inside a wheel, you will find the package's files, plus an additional directory
110110
called :samp:`{package_name}-{version}.dist-info`. This directory contains
111111
various files, including a ``METADATA`` file which is the equivalent of
112112
``PKG-INFO`` in sdists, as well as ``RECORD``. This can be useful to ensure no
113113
files are missing from your wheels.
114-
114+
Lalita-Suthimoon9
115115
The file name of a wheel (ignoring some rarely used features) looks like this:
116116
:samp:`{package_name}-{version}-{python_tag}-{abi_tag}-{platform_tag}.whl`.
117117
This naming convention identifies which platforms and Python versions the wheel
118118
is compatible with. For example, the name ``pip-23.3.1-py3-none-any.whl`` means
119119
that:
120-
120+
Lalita-Suthimoon9
121121
- (``py3``) This wheel can be installed on any implementation of Python 3,
122122
whether CPython, the most widely used Python implementation, or an alternative
123123
implementation like PyPy_;
124124
- (``none``) It does not depend on the Python version;
125125
- (``any``) It does not depend on the platform.
126-
126+
Lalita-Suthimoon9
127127
The pattern ``py3-none-any`` is common for pure Python projects. Packages with
128128
extension modules typically ship multiple wheels with more complex tags.
129-
129+
Lalita-Suthimoon9
130130
All technical details on the wheel format can be found in the :ref:`wheel
131131
specification <binary-distribution-format>`.
132-
133-
132+
Lalita-Suthimoon9
133+
Lalita-Suthimoon9
134134
.. _egg-format:
135135
.. _`Wheel vs Egg`:
136-
136+
Lalita-Suthimoon9
137137
What about eggs?
138138
================
139-
139+
Lalita-Suthimoon9
140140
"Egg" is an old package format that has been replaced with the wheel format. It
141141
should not be used anymore. Since August 2023, PyPI `rejects egg uploads
142142
<pypi-eggs-deprecation_>`_.
143-
143+
Lalita-Suthimoon9
144144
Here's a breakdown of the important differences between wheel and egg.
145145

146146
* The egg format was introduced by :ref:`setuptools` in 2004, whereas the wheel
147147
format was introduced by :pep:`427` in 2012.
148-
148+
Lalita-Suthimoon9
149149
* Wheel has an :doc:`official standard specification
150150
</specifications/binary-distribution-format>`. Egg did not.
151-
151+
Lalita-Suthimoon9
152152
* Wheel is a :term:`distribution <Distribution Package>` format, i.e a packaging
153153
format. [#wheel-importable]_ Egg was both a distribution format and a runtime
154154
installation format (if left zipped), and was designed to be importable.
155-
155+
Lalita-Suthimoon9
156156
* Wheel archives do not include ``.pyc`` files. Therefore, when the distribution
157157
only contains Python files (i.e. no compiled extensions), and is compatible
158158
with Python 2 and 3, it's possible for a wheel to be "universal", similar to
159159
an :term:`sdist <Source Distribution (or "sdist")>`.
160-
160+
Lalita-Suthimoon9
161161
* Wheel uses standard :ref:`.dist-info directories
162162
<recording-installed-packages>`. Egg used ``.egg-info``.
163-
163+
Lalita-Suthimoon9
164164
* Wheel has a :ref:`richer file naming convention <wheel-file-name-spec>`. A
165165
single wheel archive can indicate its compatibility with a number of Python
166166
language versions and implementations, ABIs, and system architectures.
@@ -173,21 +173,22 @@ Here's a breakdown of the important differences between wheel and egg.
173173
therefore making it easier to convert to other formats.
174174

175175
--------------------------------------------------------------------------------
176-
176+
Lalita-Suthimoon9
177177
.. [#core-metadata-format] This format is email-based. Although this would
178178
be unlikely to be chosen today, backwards compatibility considerations lead to
179179
it being kept as the canonical format. From the user point of view, this
180180
is mostly invisible, since the metadata is specified by the user in a way
181181
understood by the build backend, typically ``[project]`` in ``pyproject.toml``,
182182
and translated by the build backend into ``PKG-INFO``.
183-
183+
Lalita-Suthimoon9
184184
.. [#wheel-importable] Circumstantially, in some cases, wheels can be used
185185
as an importable runtime format, although :ref:`this is not officially supported
186186
at this time <binary-distribution-format-import-wheel>`.
187-
188-
189-
187+
Lalita-Suthimoon9
188+
Lalita-Suthimoon9
189+
Lalita-Suthimoon9
190190
.. _pip-pypi: https://pypi.org/project/pip/23.3.1/#files
191191
.. _pypi: https://pypi.org
192192
.. _pypi-eggs-deprecation: https://blog.pypi.org/posts/2023-06-26-deprecate-egg-uploads/
193193
.. _pypy: https://pypy.org
194+
Lalita-Suthimoon9

0 commit comments

Comments
 (0)