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.

Talk Python's Mastodon Michael Kennedy's Mastodon