In requirements.txt, what does tilde equals (~=) mean?
Question:
In the requirements.txt for a Python library I am using, one of the requirements is specified like:
mock-django~=0.6.10
What does ~= mean?
Answers:
It means it will select the latest version of the package, greater than or equal to 0.6.10, but still in the 0.6.* version, so it won’t download 0.7.0 for example. It ensures you will get security fixes but keep backward-compatibility, if the package maintainer respects the semantic versioning (which states that breaking changes should occur only in major versions).
Or, as said by PEP 440:
For a given release identifier V.N , the compatible release clause is approximately equivalent to the pair of comparison clauses:
>= V.N, == V.*
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.
You can read more here: https://www.python.org/dev/peps/pep-0440/#compatible-release
That’s the ‘compatible release’ version specifier.
It’s equivalent to: mock-django >= 0.6.10, == 0.6.*, and is a tidy way of matching a version which is expected to be compatible. In plain English, it’s a bit like saying: “I need a version of mock-django which is at least as new as 0.6.10, but not so new that it isn’t compatible with it.”
If you’re not sure about all this version number stuff, a quick look at the PEP440 version scheme should sort you out!
~= means a compatible version. Not less than 0.6.10 and higher (0.6.*).
Adding to the existing answers, I think it’s very important to also mention that while
~=0.6.10 means >=0.6.10, ==0.6.*
Following is also true
~=0.6 means >=0.6, ==0.*
It’s mentioned in the PEP documentation.
The full definition of ~= Compatible release (including pre and post release) is:
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.
The specified version identifier must be in the standard format
described in Version scheme. Local version identifiers are NOT
permitted in this version specifier.
For a given release identifier V.N, the compatible release clause is
approximately equivalent to the pair of comparison clauses:
>= V.N, == V.*
This operator MUST NOT be used with a single segment version number such as ~=1.
For example, the following groups of version clauses are equivalent:
~= 2.2
>= 2.2, == 2.*
~= 1.4.5
>= 1.4.5, == 1.4.*
If a pre-release, post-release or developmental release is named in a
compatible release clause as V.N.suffix, then the suffix is ignored
when determining the required prefix match:
~= 2.2.post3
>= 2.2.post3, == 2.*
~= 1.4.5a4
>= 1.4.5a4, == 1.4.*
The padding rules for release segment comparisons means that the
assumed degree of forward compatibility in a compatible release clause
can be controlled by appending additional zeros to the version
specifier:
~= 2.2.0
>= 2.2.0, == 2.2.*
~= 1.4.5.0
>= 1.4.5.0, == 1.4.5.*
In the requirements.txt for a Python library I am using, one of the requirements is specified like:
mock-django~=0.6.10
What does ~= mean?
It means it will select the latest version of the package, greater than or equal to 0.6.10, but still in the 0.6.* version, so it won’t download 0.7.0 for example. It ensures you will get security fixes but keep backward-compatibility, if the package maintainer respects the semantic versioning (which states that breaking changes should occur only in major versions).
Or, as said by PEP 440:
For a given release identifier V.N , the compatible release clause is approximately equivalent to the pair of comparison clauses:
>= V.N, == V.*
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.
You can read more here: https://www.python.org/dev/peps/pep-0440/#compatible-release
That’s the ‘compatible release’ version specifier.
It’s equivalent to: mock-django >= 0.6.10, == 0.6.*, and is a tidy way of matching a version which is expected to be compatible. In plain English, it’s a bit like saying: “I need a version of mock-django which is at least as new as 0.6.10, but not so new that it isn’t compatible with it.”
If you’re not sure about all this version number stuff, a quick look at the PEP440 version scheme should sort you out!
~= means a compatible version. Not less than 0.6.10 and higher (0.6.*).
Adding to the existing answers, I think it’s very important to also mention that while
~=0.6.10 means >=0.6.10, ==0.6.*
Following is also true
~=0.6 means >=0.6, ==0.*
It’s mentioned in the PEP documentation.
The full definition of ~= Compatible release (including pre and post release) is:
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.The specified version identifier must be in the standard format
described in Version scheme. Local version identifiers are NOT
permitted in this version specifier.For a given release identifier
V.N, the compatible release clause is
approximately equivalent to the pair of comparison clauses:
>= V.N, == V.*
This operator MUST NOT be used with a single segment version number such as
~=1.For example, the following groups of version clauses are equivalent:
~= 2.2
>= 2.2, == 2.*
~= 1.4.5
>= 1.4.5, == 1.4.*
If a pre-release, post-release or developmental release is named in a
compatible release clause asV.N.suffix, then the suffix is ignored
when determining the required prefix match:
~= 2.2.post3
>= 2.2.post3, == 2.*
~= 1.4.5a4
>= 1.4.5a4, == 1.4.*
The padding rules for release segment comparisons means that the
assumed degree of forward compatibility in a compatible release clause
can be controlled by appending additional zeros to the version
specifier:
~= 2.2.0
>= 2.2.0, == 2.2.*
~= 1.4.5.0
>= 1.4.5.0, == 1.4.5.*