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