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