Managing Python Dependencies Transcripts
Chapter: Setting Up Reproducible Environments & Application Deploys
Lecture: Requirements Files Best Practices
0:02 Now that you have a good idea about how requirements files work,
0:05 and how you can leverage them to organize your Python dependencies, p
0:09 let's talk about some best practices
0:11 for structuring and organizing your requirements files.
0:14 When it comes to version specifiers, it's a good idea to use
0:18 exact versioning most of the time, this is also called pinning
0:22 and it means that you lock down the exact version
0:25 of a package that will be installed, trust me,
0:28 this will help you avoid headaches in the long run.
0:31 It's also important that you include secondary dependencies
0:34 in their exact version numbers.
0:36 If you don't include secondary dependencies and pin them down to exact versions,
0:41 what can happen is that a secondary dependency gets silently upgraded
0:45 on the next deploy and that might break your application.
0:48 So my recommendation here would be to use exact versions
0:52 for all of your packages including secondary dependencies.
0:56 Now it may make sense to go without a version specifier
1:00 for some development dependencies,
1:02 for example, if you're using a third party debugger,
1:05 like ipdb or pdbpp it can make sense to leave that unpinned
1:10 so that you can always work with the latest version.
1:13 Personally, I am leaning towards pinning as many packages as possible.
1:17 From personal experience, I know that this can help avoid a lot of trouble.
1:21 When it comes to naming your requirements files
1:26 the most popular choice seems to be requirements.txt
1:30 and then also requirements-dev.txt file for those development dependencies.
1:36 Other popular choices for requirements files names,
1:39 include requirements.pip or requirements.lock but really,
1:44 this is just a naming convention and those files would function
1:47 exactly the same as the requirements.txt files you've seen before.
1:52 Whatever you name your file, typically they would be placed
1:55 in the root folder of your project, some projects also create
1:58 a separate requirements folder,
2:01 but services like Heroku typically expect that the requirements file
2:05 sits in the root folder of the project so if you go with this convention,
2:08 it usually makes things a little bit easier for you
2:11 because you won't have to overwrite config variables
2:14 and point them to a non standard location for your requirements files.
2:18 That is why I would recommend that you always
2:20 put them into the root folder of your project.
2:22 One more handy feature in requirements files is that they support comments,
2:27 you can see this in the example here, all you need to do is place a hash character,
2:32 serve like a Python comment and then all text behind that is going to be ignored.
2:37 It's a great idea to use comments in your requirements files,
2:42 for example, you could use them to explain the difference
2:45 between your requirements.txt file and the requirements-dev.txt file,
2:50 this will be helpful for any developer working with the project in the future.
2:55 Or you could leave a comment on a specific dependency
2:57 to explain your choice or to explain why a specific version is needed,
3:02 adding comments to your requirements files is a great idea.
3:06 There is a common question around
3:09 ordering dependencies inside requirements files,
3:12 so should you order them, what order should you put them in,
3:16 usually I start my requirements files with the direct dependencies,
3:20 so these would be the dependencies that
3:22 I initially installed using the pip install command,
3:25 this would include packages like requests, or Flask,
3:29 and I like to sort them alphabetically because that makes it easier
3:33 to find what I am looking for.
3:35 Then, after those direct dependencies I would put a section
3:38 with secondary dependencies and I usually use comments
3:41 to indicate the difference between the two.
3:44 So all of these secondary dependencies are dependencies
3:46 that I didn't install directly through pip install
3:49 but they were installed because a direct dependency required them.
3:53 For example here, if you pip install Flask it will bring in the
3:57 Jinja2 templating library and also the Werkzeug library.
4:01 So my typical workflow here would be to capture all dependencies
4:05 using the pip freeze command and then go through them
4:08 in an editor to split them into direct dependencies
4:11 and secondary dependencies and perform the ordering.
4:14 When you do a pip install using that requirements file
4:16 pip will figure out the right order to install your packages in
4:20 so you don't have to worry about breaking things by changing the order.
4:23 Another best practice that you already learned about
4:26 is the development and production environment split.
4:29 Pip allows you to link up requirements files so that when you install one,
4:32 pip will go out and actually also install the other,
4:35 there is a whole lesson for that in the course, so you might want to rewatch that,
4:39 as it's a highly recommended and very useful feature.
4:41 Let's do a quick recap here, those were the requirements files
4:44 best practices that you just learned,
4:47 first, you learned about the importance of version pinning,
4:50 second, we discussed naming schemes for requirements files,
4:52 after that, you learned how to use comments in requirements files
4:55 and then you learned how you can make your requirements files
4:58 easier to understand by splitting the dependencies into first order
5:02 and secondary dependencies.
5:04 And finally, we did a quick recap on the technique that allows you
5:07 to split up your development and production dependencies.
5:09 If you follow these conventions, and best practices,
5:12 it will make it easier for other developers to work with your Python projects.