pyproject.tomlsetup.py based project?This page specifies the binary distribution format for Python packages,also called the wheel format.
A wheel is a ZIP-format archive with a specially formatted file name andthe.whl extension. It contains a single distribution nearly as itwould be installed according to PEP 376 with a particular installationscheme. Although a specialized installer is recommended, a wheel filemay be installed by simply unpacking into site-packages with the standard‘unzip’ tool while preserving enough information to spread its contentsout onto their final paths at any later time.
Wheel installation notionally consists of two phases:
Unpack.
Parsedistribution-1.0.dist-info/WHEEL.
Check that installer is compatible with Wheel-Version. Warn ifminor version is greater, abort if major version is greater.
If Root-Is-Purelib == ‘true’, unpack archive into purelib(site-packages).
Else unpack archive into platlib (site-packages).
Spread.
Unpacked archive includesdistribution-1.0.dist-info/ and (ifthere is data)distribution-1.0.data/.
Move each subtree ofdistribution-1.0.data/ onto itsdestination path. Each subdirectory ofdistribution-1.0.data/is a key into a dict of destination directories, such asdistribution-1.0.data/(purelib|platlib|headers|scripts|data).These subdirectories areinstallation paths defined by sysconfig.
If applicable, update scripts starting with#!python to pointto the correct interpreter.
Updatedistribution-1.0.dist-info/RECORD with the installedpaths.
Remove emptydistribution-1.0.data directory.
Compile any installed .py to .pyc. (Uninstallers should be smartenough to remove .pyc even if it is not mentioned in RECORD.)
#!python.In wheel, scripts are packaged in{distribution}-{version}.data/scripts/. If the first line ofa file inscripts/ starts with exactlyb'#!python', rewrite topoint to the correct interpreter. Unix installers may need to addthe +x bit to these files if the archive was created on Windows.
Theb'#!pythonw' convention is allowed.b'#!pythonw' indicatesa GUI script instead of a console script.
In wheel, scripts packaged on Unix systems will certainly not haveaccompanying .exe wrappers. Windows installers may want to add themduring install.
.dist-info at the end of the archive.Archivers are encouraged to place the.dist-info files physicallyat the end of the archive. This enables some potentially interestingZIP tricks including the ability to amend the metadata withoutrewriting the entire archive.
The wheel filename is{distribution}-{version}(-{buildtag})?-{pythontag}-{abitag}-{platformtag}.whl.
Distribution name, e.g. ‘django’, ‘pyramid’.
Distribution version, e.g. 1.0.
Optional build number. Must start with a digit. Acts as atie-breaker if two wheel file names are the same in all otherrespects (i.e. name, version, and other tags). Sort as anempty tuple if unspecified, else sort as a two-item tuple withthe first item being the initial digits as anint, and thesecond item being the remainder of the tag as astr.
A common use-case for build numbers is rebuilding a binarydistribution due to a change in the build environment,like when using the manylinux image to builddistributions using pre-release CPython versions.
Warning
Build numbers are not a part of the distribution version and thus are difficultto reference externally, especially so outside the Python ecosystem of tools and standards.A common case where a distribution would need to referenced externally is whenresolving a security vulnerability.
Due to this limitation, new distributions which need to be referenced externallyshould not use build numbers when building the new distribution.Instead anew distribution version should be created for such cases.
E.g. ‘py27’, ‘py2’, ‘py3’.
E.g. ‘cp33m’, ‘abi3’, ‘none’.
E.g. ‘linux_x86_64’, ‘any’.
For example,distribution-1.0-1-py27-none-any.whl is the firstbuild of a package called ‘distribution’, and is compatible withPython 2.7 (any Python 2.7 implementation), with no ABI (pure Python),on any CPU architecture.
The last three components of the filename before the extension arecalled “compatibility tags.” The compatibility tags express thepackage’s basic interpreter requirements and are detailed in PEP 425.
As the components of the filename are separated by a dash (-, HYPHEN-MINUS),this character cannot appear within any component. This is handled as follows:
In distribution names, any run of-_. characters (HYPHEN-MINUS, LOW LINEand FULL STOP) should be replaced with_ (LOW LINE), and uppercasecharacters should be replaced with corresponding lowercase ones. This isequivalent to regularname normalization followedby replacing- with_. Tools consuming wheels must be prepared to accept. (FULL STOP) and uppercase letters, however, as these were allowed by an earlierversion of this specification.
Version numbers should be normalised according to theVersion specifierspecification. Normalised version numbers cannot contain-.
The remaining components may not contain- characters, so no escapingis necessary.
Tools producing wheels should verify that the filename components do not contain-, as the resulting file may not be processed correctly if they do.
The archive filename is Unicode. It will be some time before the toolsare updated to support non-ASCII filenames, but they are supported inthis specification.
The filenamesinside the archive are encoded as UTF-8. Although someZIP clients in common use do not properly display UTF-8 filenames,the encoding is supported by both the ZIP specification and Python’szipfile.
The contents of a wheel file, where {distribution} is replaced with thenormalized name of the package, e.g.beaglevote and {version} is replacedwith itsnormalized version,e.g.1.0.0, (with dash/- characters replaced with underscore/_ charactersin both fields) consist of:
/, the root of the archive, contains all files to be installed inpurelib orplatlib as specified inWHEEL.purelib andplatlib are usually bothsite-packages.
{distribution}-{version}.dist-info/ contains metadata.
distribution-version.dist-info/licenses/ contains license files.
{distribution}-{version}.data/ contains one subdirectoryfor each non-empty install scheme key not already covered, wherethe subdirectory name is an index into a dictionary of install paths(e.g.data,scripts,headers,purelib,platlib).
Python scripts must appear inscripts and begin with exactlyb'#!python' in order to enjoy script wrapper generation and#!python rewriting at install time. They may have any or noextension. Thescripts directory may only contain regular files.
{distribution}-{version}.dist-info/METADATA is Metadata version 1.1or greater format metadata.
{distribution}-{version}.dist-info/WHEEL is metadata about the archiveitself in the same basic key: value format:
Wheel-Version: 1.0Generator: bdist_wheel 1.0Root-Is-Purelib: trueTag: py2-none-anyTag: py3-none-anyBuild: 1
Wheel-Version is the version number of the Wheel specification.
Generator is the name and optionally the version of the softwarethat produced the archive.
Root-Is-Purelib is true if the top level directory of the archiveshould be installed into purelib; otherwise the root should be installedinto platlib.
Tag is the wheel’s expanded compatibility tags; in the example thefilename would containpy2.py3-none-any.
Build is the build number and is omitted if there is no build number.
A wheel installer should warn if Wheel-Version is greater than theversion it supports, and must fail if Wheel-Version has a greatermajor version than the version it supports.
Wheel, being an installation format that is intended to work acrossmultiple versions of Python, does not generally include .pyc files.
Wheel does not contain setup.py or setup.cfg.
This version of the wheel specification is based on the distutils installschemes and does not define how to install files to other locations.The layout offers a superset of the functionality provided by the existingwininst and egg binary formats.
Wheel .dist-info directories include at a minimum METADATA, WHEEL,and RECORD.
METADATA is the package metadata, the same format as PKG-INFO asfound at the root of sdists.
WHEEL is the wheel metadata specific to a build of the package.
RECORD is a list of (almost) all the files in the wheel and theirsecure hashes. Unlike PEP 376, every file except RECORD, whichcannot contain a hash of itself, must include its hash. The hashalgorithm must be sha256 or better; specifically, md5 and sha1 arenot permitted, as signed wheel files rely on the strong hashes inRECORD to validate the integrity of the archive.
PEP 376’s INSTALLER and REQUESTED are not included in the archive.
RECORD.jws is used for digital signatures. It is not mentioned inRECORD.
RECORD.p7s is allowed as a courtesy to anyone who would prefer touse S/MIME signatures to secure their wheel files. It is notmentioned in RECORD.
During extraction, wheel installers verify all the hashes in RECORDagainst the file contents. Apart from RECORD and its signatures,installation will fail if any file in the archive is not bothmentioned and correctly hashed in RECORD.
.dist-info/¶Subdirectories under.dist-info/ are reserved for future use.The following subdirectory names under.dist-info/ are reserved for specific usage:
Subdirectory name | PEP / Standard |
|---|---|
| |
| |
| |
|
.dist-info/licenses/ directory¶If the metadata version is 2.4 or greater and one or moreLicense-Filefields is specified, the.dist-info/ directory MUST contain alicenses/ subdirectory, which MUST contain the files listed in theLicense-File fields in theMETADATA file at their respective pathsrelative to thelicenses/ directory.
.dist-info/sboms/ directory¶All files contained within the.dist-info/sboms/ directory MUSTbe Software Bill-of-Materials (SBOM) files that describe software containedwithin the distribution archive.
Any file that is not normally installed inside site-packages goes intothe .data directory, named as the .dist-info directory but with the.data/ extension:
distribution-1.0.dist-info/distribution-1.0.data/
The .data directory contains subdirectories with the scripts, headers,documentation and so forth from the distribution. During installation thecontents of these subdirectories are moved onto their destination paths.
Wheel files include an extended RECORD that enables digitalsignatures. PEP 376’s RECORD is altered to include a secure hashdigestname=urlsafe_b64encode_nopad(digest) (urlsafe base64encoding with no trailing = characters) as the second column insteadof an md5sum. All possible entries are hashed, including anygenerated files such as .pyc files, but not RECORD which cannot contain itsown hash. For example:
file.py,sha256=AVTFPZpEKzuHr7OvQZmhaU3LvwKz06AJw8mT\_pNh2yI,3144distribution-1.0.dist-info/RECORD,,
The signature file(s) RECORD.jws and RECORD.p7s are not mentioned inRECORD at all since they can only be added after RECORD is generated.Every other file in the archive must have a correct hash in RECORDor the installation will fail.
If JSON web signatures are used, one or more JSON Web Signature JSONSerialization (JWS-JS) signatures is stored in a file RECORD.jws adjacentto RECORD. JWS is used to sign RECORD by including the SHA-256 hash ofRECORD as the signature’s JSON payload:
{"hash":"sha256=ADD-r2urObZHcxBW3Cr-vDCu5RJwT4CaRTHiFmbcIYY"}
(The hash value is the same format used in RECORD.)
If RECORD.p7s is used, it must contain a detached S/MIME format signatureof RECORD.
A wheel installer is not required to understand digital signatures butMUST verify the hashes in RECORD against the extracted file contents.When the installer checks file hashes against RECORD, a separate signaturechecker only needs to establish that RECORD matches the signature.
See
This specification does not have an opinion on how you should organizeyour code. The .data directory is just a place for any files that arenot normally installed inside
site-packagesor on the PYTHONPATH.In other words, you may continue to usepkgutil.get_data(package,resource)even thoughthose files will usually not be distributedinwheel’s.datadirectory.
Attached signatures are more convenient than detached signaturesbecause they travel with the archive. Since only the individual filesare signed, the archive can be recompressed without invalidatingthe signature or individual files can be verified without havingto download the whole archive.
The JOSE specifications of which JWS is a part are designed to be easyto implement, a feature that is also one of wheel’s primary designgoals. JWS yields a useful, concise pure-Python implementation.
S/MIME signatures are allowed for users who need or want to useexisting public key infrastructure with wheel.
Signed packages are only a basic building block in a secure packageupdate system. Wheel only provides the building block.
Wheel preserves the “purelib” vs. “platlib” distinction, which issignificant on some platforms. For example, Fedora installs purePython packages to ‘/usr/lib/pythonX.Y/site-packages’ and platformdependent packages to ‘/usr/lib64/pythonX.Y/site-packages’.
A wheel with “Root-Is-Purelib: false” with all its filesin
{name}-{version}.data/purelibis equivalent to a wheel with“Root-Is-Purelib: true” with those same files in the root, and itis legal to have files in both the “purelib” and “platlib” categories.In practice a wheel should have only one of “purelib” or “platlib”depending on whether it is pure Python or not and those files shouldbe at the root with the appropriate setting given for “Root-is-purelib”.
Technically, due to the combination of supporting installation viasimple extraction and using an archive format that is compatible with
zipimport, a subset of wheel filesdo support being placed directlyonsys.path. However, while this behaviour is a natural consequenceof the format design, actually relying on it is generally discouraged.Firstly, wheelis designed primarily as a distribution format, soskipping the installation step also means deliberately avoiding anyreliance on features that assume full installation (such as being ableto use standard tools like
pipandvirtualenvto capture andmanage dependencies in a way that can be properly tracked for auditingand security update purposes, or integrating fully with the standardbuild machinery for C extensions by publishing header files in theappropriate place).Secondly, while some Python software is written to support runningdirectly from a zip archive, it is still common for code to be writtenassuming it has been fully installed. When that assumption is brokenby trying to run the software from a zip archive, the failures can oftenbe obscure and hard to diagnose (especially when they occur in thirdparty libraries). The two most common sources of problems with thisare the fact that importing C extensions from a zip archive isnotsupported by CPython (since doing so is not supported directly by thedynamic loading machinery on any platform) and that when running froma zip archive the
__file__attribute no longer refers to anordinary filesystem path, but to a combination path that includesboth the location of the zip archive on the filesystem and therelative path to the module inside the archive. Even when softwarecorrectly uses the abstract resource APIs internally, interfacing withexternal components may still require the availability of an actualon-disk file.Like metaclasses, monkeypatching and metapath importers, if you’re notalready sure you need to take advantage of this feature, you almostcertainly don’t need it. If youdo decide to use it anyway, beaware that many projects will require a failure to be reproduced witha fully installed package before accepting it as a genuine bug.
February 2013: This specification was approved throughPEP 427.
February 2021: The rules on escaping in wheel filenames were revised, to bringthem into line with what popular tools actually do.
December 2024: Clarified that thescripts folder should only containregular files (the expected behaviour of consuming tools when encounteringsymlinks or subdirectories in this folder is not formally defined, and hencemay vary between tools).
December 2024: The.dist-info/licenses/ directory was specified throughPEP 639.
January 2025: Clarified that name and version needs to be normalized for.dist-info and.data directories.
Example urlsafe-base64-nopad implementation:
# urlsafe-base64-nopad for Python 3import base64def urlsafe_b64encode_nopad(data): return base64.urlsafe_b64encode(data).rstrip(b'=')def urlsafe_b64decode_nopad(data): pad = b'=' * (4 - (len(data) & 3)) return base64.urlsafe_b64decode(data + pad)