Do these 3 things before closing this tab:
1Clear out junk files and repair common Windows errors2Scan for outdated or missing drivers - takes under a minute3Repair Windows errors before they cause bigger problemsA source distribution (sdist) is a source archive intended to provide the inputs needed to build a package; a wheel is a built archive containing files prepared for installation. Neither format promises a complete copy of a project’s development checkout. The exact optional files depend on the project’s build configuration, so inspect the release artifact to know its full contents.
What an sdist includes
The current standardized source distribution is a gzip-compressed tar archive with one top-level {name}-{version} directory. Under the PyPA source distribution format specification, that directory must contain pyproject.toml and PKG-INFO. The metadata must conform to at least metadata version 2.2.
When the metadata uses version 2.4 or later, the archive must also contain license files named in License-File, at the relative paths declared there. Beyond those requirements, the format does not define a universal file inventory.
Common project files are not guaranteed
An sdist may include source code, tests, documentation, generated files, or backend-specific build material. Those are possibilities, not requirements for every package. Build-system configuration determines which additional files are included; PyPA describes an sdist as carrying source needed for installation and notes that projects may include tests and documentation in its packaging flow guide.
#1 Best Overall
What a wheel includes
A wheel is a ZIP-format built distribution. Its archive root contains files destined for the Python installation scheme’s purelib or platlib locations, commonly site-packages, plus a {distribution}-{version}.dist-info/ directory. The binary distribution format specification requires that .dist-info include at least METADATA, WHEEL, and RECORD; the latter records archive files and hashes.
License files go in .dist-info/licenses/. If files are intended for installation outside the default library locations, a wheel can also contain a {distribution}-{version}.data/ directory. Its subdirectories use installation-scheme keys such as scripts, headers, or data.
Does a wheel include source code?
It can include Python source files when those are the files the package installs. But a wheel is not a source archive or a copy of the development checkout. For a package with compiled extensions, the wheel contains built executable code for its target, not necessarily the C, C++, or Rust source used to create it. Pure-Python wheels can often work across more systems; compiled wheels carry compatibility tags for relevant interpreter, operating-system, and architecture constraints.
The wheel specification says wheels do not generally include .pyc files and do not contain setup.py or setup.cfg. A README may be incorporated into distribution metadata without being included as a standalone installed file; its presence as a file depends on the backend and project configuration. See PyPA’s README guidance.
At a glance: how their contents differ
| What to look for | Source distribution (sdist) | Wheel |
|---|---|---|
| Format and purpose | Gzip-compressed tar archive intended to provide source and build inputs. | ZIP-format built distribution prepared for installation. |
| Required structure | One top-level {name}-{version} directory containing pyproject.toml and PKG-INFO. |
Install-scheme files and a .dist-info directory containing at least METADATA, WHEEL, and RECORD. |
| Tests and documentation | May be included; not universally required. | Not guaranteed; the archive is for installation rather than a full development checkout. |
| Compiled code | May include source used to build extensions. | For compiled packages, contains built code for the wheel’s target compatibility. |
| Other installation locations | Not defined as a standard installed-file layout. | May use a .data directory grouped by scheme key. |
The required-structure descriptions in the table follow the PyPA sdist and wheel specifications. Optional contents vary by project.
Why pip may download an sdist
pip uses a compatible wheel when one is available. If it cannot find a wheel compatible with the current environment, it can download the sdist, build a wheel locally, and install that result. This is especially relevant for packages with compiled extensions: a release may not offer a prebuilt wheel for every supported Python, operating system, and CPU combination. PyPA explains this behavior in its installing packages guide.
For publishers, PyPA recommends distributing an sdist and one or more wheels. A pure-Python package often needs one generic wheel, while a package with binary extensions may need wheels for each supported compatibility combination. See the packaging flow guide.
Independent reader supportYour contribution helps us test, update, and keep practical guides available for everyone.How to inspect the files in a specific release
- Download the exact sdist or wheel release you want to check.
- List or extract the sdist with standard tar tools, or list the wheel with ZIP archive tools.
- For an sdist, check the top-level directory,
pyproject.toml,PKG-INFO, source files, and any project-specific extras. - For a wheel, inspect its root files,
.dist-info, any.datadirectory, and the compatibility tags in its filename andWHEELmetadata.
Artifact inspection is the way to establish whether a particular release includes optional items such as tests or documentation; the format rules alone cannot answer that. To build artifacts from a project, PyPA identifies build as the standard tool for invoking the backend in pyproject.toml and advises against using python setup.py sdist or python setup.py bdist_wheel for this task. See its tool recommendations.
Quick Recap
Product prices and availability are accurate as of the date/time indicated and are subject to change. Any price and availability information displayed on Amazon at the time of purchase will apply.
