In requirements.txt, what does tilde equals (~=) mean?

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.*

• Definition in PEP 440

• Complete example here in the documentation

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!

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.

~= means a compatible version. Not less than 0.6.10 and higher (0.6.*).

> 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

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.*