The comma is equivalent to a logical AND operator: a candidate version must match all given version clauses in order to match the specifier as a whole.
A version matching clause includes the version matching operator == and a version identifier.
By default, the version matching operator is based on a strict equality comparison: the specified version must be exactly the same as the requested version.
Clause
Allowed versions
==1
1.0.0
==1.2
1.2.0
Prefix matching may be requested instead of strict comparison, by appending a trailing .* to the version identifier in the version matching clause. This means that additional trailing segments will be ignored when determining whether or not a version identifier matches the clause.
A compatible release clause consists of the compatible release operator ~= and a version identifier. It matches any candidate version that is expected to be compatible with the specified version.
For a given release identifier V.N, the compatible release clause is approximately equivalent to the following pair of comparison clauses:
>= V.N, == V.*
This operator cannot be used with a single segment version number such as ~=1.
A version exclusion clause includes the version exclusion operator != and a version identifier.
The allowed version identifiers and comparison semantics are the same as those of the Version matching operator, except that the sense of any match is inverted.
Inclusive comparisons allow for the version identifier part of clauses whereas exclusive comparisons do not. For example, >=1.2 allows for version 1.2.0 while >1.2 does not.
Unlike the inclusive ordered comparisons <= and >=, the exclusive ordered comparisons < and > specifically exclude pre-releases, post-releases, and local versions of the specified version.
Environment markers allow for dependencies to only be installed when certain conditions are met.
For example, if you need to install the latest version of cryptography that is available for a given Python major version you could define the following:
Feature groups can self-referentially extend others. For example, for a project called awesome-project, the dev feature group in the following pyproject.toml file would select everything in the crypto feature group, plus black:
Instead of using normal version specifiers and fetching packages from an index like PyPI, you can define exact sources using direct references with an explicit URI.
Direct references are usually not meant to be used for dependencies of a published project but rather are used for defining dependencies for an environment.
All direct reference types are prefixed by the package name like:
You may also append a #subdirectory=<PATH> component for specifying the relative path to the Python package when it is not located at the root e.g. #subdirectory=lib/foo.
You can install local packages with the file scheme in the following format:
<NAME> @ file://<HOST>/<PATH>
The <HOST> is only used on Windows systems, where it can refer to a network share. If omitted it is assumed to be localhost and the third slash must still be present.
The <PATH> can refer to a source archive, a wheel, or a directory containing a Python package.
Type
Unix
Windows
Source archive
proj @ file:///path/to/pkg.tar.gz
proj @ file:///c:/path/to/pkg.tar.gz
Wheel
proj @ file:///path/to/pkg.whl
proj @ file:///c:/path/to/pkg.whl
Directory
proj @ file:///path/to/pkg
proj @ file:///c:/path/to/pkg
Tip
You may also specify paths relative to your project's root directory on all platforms by using context formatting:
If the hash differs from the expected hash, the installation will fail.
It is recommended that only hashes which are unconditionally provided by the latest version of the standard library's hashlib module be used for hashes. As of Python 3.10, that list consists of: