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,
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.
