Modern Python Projects Transcripts
Chapter: Managing Python project
Lecture: requirements.txt conventions
Login or
purchase this course
to watch this video and the rest of the course contents.
0:00
There are three common ways to specify a dependency inside the requirements file.
0:05
First is to specify the name of the package, and which version you want. This notation is using something called semantic versioning,
0:14
where each package specifies three numbers. First one is the major version. Then we have minor version, and finally we have the patch version.
0:22
The major version usually means that there are some big changes in a package, and they can break some functionality.
0:28
So, you need to be careful when you update the major version. Minor version is not that drastic,
0:34
and usually it means adding new features without breaking the old ones,
0:38
although it can happen that some features will be removed between minor versions. But in this case, it's a common practice to display a warning,
0:47
saying something like, Hey, this feature is going to be removed in the next version, so you better be careful.
0:53
And finally, the last number is a patch version. Whenever a serious bad or a security vulnerability is fixed in a given package,
1:01
a new version of this package is released and this last number is incremented.
1:07
It's not only safe to update your package to the latest possible patch version.
1:12
But it's also recommended to do this as soon as possible, because it means that the previous version has a bad that someone might exploit.
1:19
Version numbers are quite flexible, and you are not limited to a specific version.
1:24
You can use less than(<) or greater than (>) operator to specify that you want to have a Django version at least 2.2 or newer.
1:32
Or you can say that you want to have, a Django version, that it's less than 3.0 because you know that your application won't
1:39
work with Django 3. It's also very common to combine those two conditions. For example, you want to install Django 2.2 or higher,
1:46
but still less than Django 3. So, you combine both operators. Another common scenario is to stay on a specific minor
1:54
version. For that, you can use this quickly equal(==) operator. It's equivalent to saying use any version of Django 3.1 as long as it's higher or
2:05
equal to Django 3.1.2. So, if a Django 3.1.3 is released, this version will be used. When Django 3.1.4 is released.
2:16
Then again, that version will be used. But if a version 3.2.0 is released, it won't be used because we said Stay on Django 3.1 And finally,
2:27
in a similar way, you can say that you want to use a specific major version. So, when the new minor or bug fixed version is released,
2:36
they will be automatically installed. But when a new major version of Django is released it won't be automatically used.
2:44
If you want to always install the latest version of a package, you can skip the version number. For example, here we want to.
2:52
Always use the latest version of pytest. And finally, not all packages are available on pypi, maybe some of them are stored on a private pypi server.
3:02
Or maybe you want to install the latest version directly from GitHub.
3:07
That's also possible. You can specify a Github branch or a tag, and pip will install this specific version of package from GitHub.