Python Dependency Management: pip and Beyond Course

Welcome to managing Python dependencies with pip and virtual environments.
Dependency management and managing third party Python packages is a super important topic for any professional Python developer.
In my experience, even if you begin with a simple question like how do I install a third party Python package, you can quickly go down a rabbit hole of other tools and new questions that pop up, and it can quickly get overwhelming.
This course will be your one-stop shop for becoming proficient at dependency management with Python.
Let's take a look at the course goals.
By the end of the course, you will know how to install, use and manage third party Python packages with the pip package manager; you will know how to isolate your project dependencies with so called virtual environments; you will know a complete workflow for finding and identifying quality third party packages that you can use in your own Python projects.
You will also know how to set up repeatable development environments and application deployments with a complete workflow for that using requirements files.
If you're wondering who the disembodied voice inside your computer is, hey that is me, Dan Bader, I am a complete Python nut and I would love to help you improve your Python skills.
I started writing code when I was eight years old and was hacking away on my Commodore 64, and I never stopped since.
Programming is a complete passion for me and I eventually got a bachelor's and master's degree in computer science.
I worked in full time positions for a few years, first as a software engineer, and then later as a lead developer and today I am an independent software developer and consultant, I run a number of Python projects and I've also been a speaker at various conferences around the world.
If you want some more Python learning resources, check out my website at dbader.org I've got tons more tutorials and videos that will help you master Python.
Alright, enough about me, let's take a look at the course curriculum.
Right now, you're in the first module on the course "The welcome and course overview" module.
Every time I show you the course curriculum, I will always highlight in bold text where you are at the moment.
So next up you'll dive into "Managing third party dependencies with Pip" and then after that, you'll learn how to isolate your project dependencies with virtual environments.
In the fourth module, you'll learn a complete workflow for finding and researching quality Python packages.
Next, you'll learn how to set up reproducible environment and application deploys.
And finally, in the sixth module there will be the course conclusion and a quick recap.
That's the course curriculum.
Now, this will be a really practical course, in each module you'll encounter a mixture of slight base presentations and hands on life demos, so you can see and follow along with the exact workflows that I used to research and find Python packages or to manage dependencies in my own Python projects.
Well, congratulations, you've just completed the first module in the course.
Time to jump in and learn about managing third party dependencies with pip.

Welcome to your course i want to take just a quick moment to take you on a tour, the video player in all of its features so that you get the most out of this entire course and all the courses you take with us so you'll start your course page of course, and you can see that it graze out and collapses the work they've already done so let's, go to the next video here opens up this separate player and you could see it a standard video player stuff you can pause for play you can actually skip back a few seconds or skip forward a few more you can jump to the next or previous lecture things like that shows you which chapter in which lecture topic you're learning right now and as other cool stuff like take me to the course page, show me the full transcript dialogue for this lecture take me to get home repo where the source code for this course lives and even do full text search and when we have transcripts that's searching every spoken word in the entire video not just titles and description that things like that also some social media stuff up there as well.
For those of you who have a hard time hearing or don't speak english is your first language we have subtitles from the transcripts, so if you turn on subtitles right here, you'll be able to follow along as this words are spoken on the screen.
I know that could be a big help to some of you just cause this is a web app doesn't mean you can't use your keyboard.
You want a pause and play?
Use your space bar to top of that, you want to skip ahead or backwards left arrow, right?
Our next lecture shift left shift, right went to toggle subtitles just hit s and if you wonder what all the hockey star and click this little thing right here, it'll bring up a dialogue with all the hockey options.
Finally, you may be watching this on a tablet or even a phone, hopefully a big phone, but you might be watching this in some sort of touch screen device.
If that's true, you're probably holding with your thumb, so you click right here.
Seek back ten seconds right there to seek ahead thirty and, of course, click in the middle to toggle play or pause now on ios because the way i was works, they don't let you auto start playing videos, so you may have to click right in the middle here.
Start each lecture on iowa's that's a player now go enjoy that core.

In this part of the course, you'll learn how to manage your Python dependencies with the pip package manager.
Here is where you are int he course right now, this is the first main module in the course.
First of all, you'll learn what dependency management is and what it is good for.
Next, you'll get an introduction to pip, the Python package manager.
You'll learn how to install and update pip to the latest version, and right after that, you're going to learn about the different Python package repositories and the associated websites.
Then, you'll learn how to install Python packages with the pip command line tools.
Next, you'll learn how to identify and update outdated packages, and in the final lesson in this module, you'll learn how to uninstall or remove packages from your system.
Let's start with an introduction to dependency management.

You might have heard the term dependency management in combination with Python packaging.
What is dependency management, and what do you need it for?
So most real world programs that you are going to write and that you are going to encounter are likely to use third party libraries and frameworks.
These frameworks that the program uses and that the program requires to function are called dependencies, so here is an example.
Let's say you are working on a project called "my program" and to do its job, my program actually relies on two other packages, and so my program would enlist these other dependencies and use those other packages and other libraries to get the job done.
So maybe you don't want to reimplement some function like HTTP downloads and you program would just use that in a library and these packages "super library" and "other dependency", they would be called dependencies of my program in this case.
Of course, not only can your programs have dependencies, but the dependencies of you programs can have dependencies again, and so on, and this is what we refer to as transitive dependencies, or you could also think of them as dependencies of dependencies or secondary dependencies.
So let's take a look at our "my program" example.
So in this case, we said "my program" has two direct dependencies and that will be "super library" and "other dependency", now what you can see here is that "super library" and "other dependency" itself, actually have dependencies again, and some of the dependencies of those dependencies, have dependencies again.
So this is a whole tree of dependencies.
On the one hand, having this flexibility is great because it allows us to abstract away all kinds of functionality and then make that available to other programs and other libraries, so that the community of Python developers can build increasingly powerful libraries and programs and frameworks.
But on the other hand, I am sure you're starting to see why managing dependencies manually is so difficult, it's super time consuming, copying and pasting source code makes updating really difficult, imagine you downloaded some file off the internet, some Python source code that you're including in your project, what happens if you want to update that file- maybe a new version came out or the author released a new version, and you want to include that in your program to make use of some awesome new features.
Now, if you have to manually copy and paste that around it's very easy to make mistakes and it's kind of hard to understand what the real dependencies of a program are.
So if you are sending that over to a co-worker or you want to publish that program on the internet, it becomes very hard for everyone else to actually understand what dependencies they would need to install in order to get your program to run.
The solution to all of these problems is of course, more software; You know, I am joking here, but, there is software that can make your life a little bit easier when it comes to dependency management, and this software is typically referred to as package managers.

The recommended package manager for Python is called pip.
Now, before I go into a little bit more detail on pip, I want to explain to you first what packages in Python are.
I am going to use the following definition here.
So a package is a bundle of software, to be installed into a Python environment.
And typically, this would include things like third party libraries and frameworks.
And I am sure you've heard about some of those, for example, Django would be a popular package in the Python world, and so would be Requests, the HTTP download library.
And then, there is Numpy, another very popular package that includes tons of different libraries and frameworks for number crunching and data science.
Time to talk about pip, the Python package manager.
Pip comes with any modern Python install, it's included by default with the rest of the Python standard library and things like the Python interpreter, pip's main interface is a command line tool, also called pip.
I am going to show you how to access pip from the command line now.
I am in my terminal here, and now I am going to run a quick version check on pip, alright, you can see here that it tells me exactly which version of pip I've got installed, and it also tells me where this version of pip lives right now.
So, here I am running Python 3.6 on macOS and pip tells me that it's using this install with the Python 3.6 site packages directory.
Pip's command line interface also has a help command.
Running the help command will show you all of the available subcommands you can use with pip and you are going to learn how to use the most important pip commands here in the course.

Before we continue, I want to make sure you actually have a working pip install at this point, and that it's fully up to date.
So let's talk about installing pip if it's not already on your system and then also how you can upgrade to the latest version of pip.
So all modern versions of Python 2 and Python 3 are going to include pip by default.
Now of course that doesn't really help you if the pip command doesn't work in your system right now, so let's talk about what you can do if pip is not available on your system yet.
The first option to get a working pip install on your system would be to upgrade to a more modern version of Python which is automatically going to include the latest version of pip.
Now, this would be my preferred option, but of course, if you're working with older legacy versions of Python and you have a bunch of code running on them already, then that isn't really the best option.
So, option 2 would be to add pip to your existing Python install, and that is definitely possible, I am going to show you how to do that now.
So in a nutshell, on macOS and Windows, you would have to download a so called bootstrap script, called get-pip.py.
And you would download that through a browser or through a command line tool like curl, and once you've downloaded the get pip script, you would run it with the Python interpreter.
So you would just go to the terminal and run something like Python get-pip.py and the get pip script would then automatically install and set up pip on your system.
Now, on most versions of Linux, especially if you're using a version based on Debian Linux like Ubuntu, you would actually go through the system package manager to install pip.
To do that, you would first run a command like sudo apt update to refresh your system's package manger and then you would follow up with sudo apt install Python-pip, and running that command would add pip to your existing Python install.
Now adding pip to an existing Python install is a little bit fiddly, there are a couple of edge cases you need to look out for, one resource that I can recommend to learn more about how to do this, is the Python packaging guide.
You can find it at packaging.Python.org.
Let's make sure you're running an up to date version of pip on your system.
Modern versions of Python will always include the latest pip version that came out when the Python release was prepared.
But, pip and Python are actually fully independent, so you can update pip without updating Python for example.
Depending on the operating system that you're on, the steps you need to take to update pip are slightly different.
On macOS and Windows you would typically just use the pip command to tell pip to upgrade itself, and I am going to give you a live demo of how to do that shortly.
On a Linux system where you are using the system package manager to manage your Python install, you would typically upgrade pip through that, so you wouldn't actually use the pip command to upgrade pip but you would just tell the system package manager to update your install of pip.
I am going to give you a live demo of how that upgrade process works.
So I am back here in my macOS terminal and I've prepared this command here, so I am running this command, sudo pip install --upgrade pip setuptools And what this is going to do, it's basically telling pip to upgrade itself.
Set up tools here is just another dependency for pip and part of the package management system in Python.
So typically, you would update both of them at the same time.
I am going to go ahead and run this command now, so because I am running this with sudo, I need to enter my account password, okay, so this worked, and what pip is telling us here is that essentially everything is up to date.
So any time you want to update pip to the latest version in the future, you would just rerun that command, and then if there is an update pip would install it and upgrade itself to the latest version.

An important part of dependency management is of course the ability to store packages somewhere so that you or other people can install them.
Now, let's talk about Python package repositories.
Python packages are collected in so called software repositories.
The biggest, or official software repository in Python is called PyPi.
It's also sometimes called the "Cheese Shop", because Python developers just love their Monty Python references.
Developers can register for a free PyPi account and then submit new packages to the repository.
And once a package appears in PyPi, everyone else can install it through pip, so this is a really popular method to distribute open source Python packages, and there are literally tens of thousands of packages available for free, that you could just install through pip.
And by the way, there is no review or QA process for packages submitted to PyPi.
So whenever you install a package from PyPi, it makes sense to invest some time into do diligence work and reviewing what's available, so that you get a quality piece of software.
Let's search for some packages on PyPi.
We're going to take a look at the PyPi website now, and you can find it at pypi.Python.org.
Lets fire up a browser and then take a look at the PyPi website.
Alright, this is PyPi, you can see some stats here so right now, they are close to a 100 thousand packages available here, on PyPi, and when you scroll down, you can see sort of a update log of recently updated packages as people pushed them to the package repository you can see here what was updated.
And of course, one of the most important parts of the site here is the search box.
So into the search box, you can enter keywords and basically do a full text search on the descriptions and the metadata for the packages available on PyPi, so you've probably heard of the really popular Requests package, which is a HTTP download library, so I am going to go ahead and search for Requests here.
Okay, so these are the search results for Requests, and what is interesting here is that the actual Requests library that I was looking for, is not the number one search result, right, because this is just doing a search across all of the descriptions and the metadata in all of the available packages.
So I get some very exhaustive results here, and you can see here as I scroll down this is a really long list, because, obviously the keyword Requests seems to be quite popular.
Alright, so I am going to go ahead and click on the Requests library here, because, every package in PyPi actually has its own landing page, so it has its own page on PyPi where the developers can host the readme and give some links to the documentation or release history, and stuff like that.
So what you can see here is that right now I am looking at the specific version of Requests, and you can also see that reflected here in the url, so this will be a pypi-name of the library-the version.
So this is handy if you ever want to link to a specific library or a specific version of library, because you can just use that link.
This is the readme file or the description that the creators of the Requests library have put together.
So the contents of this description here largely depend on the information that the library creators put in.
Sometimes the formatting as it's displayed on the PyPi website isn't perfect, so you are going to get these super blown up images here, just ignore that for now.
Actually, what I wanted to show you is when you scroll all the way down here, there will always be the summary with metadata about the package that you are looking at, and this is often very useful if you want to find the homepage for a specific project or if you want to identify its author or if you are interested in the license that the code is under.
Then, also, you can see the categories the code is filed under, or the library it was filed under, and then also what other dependencies or secondary dependencies that library requires.
To me, the most useful information is usually these top 3 items here, I want to know about the library author, I usually take a look at the library home page and then I also want to know what license the software is under.
And of course, you could also click through these categories here and maybe find some interesting packages that way.
Okay, that's it for PyPi.
You can also search for packages from the command line, using the pip search command.
Usually I would recommend that you stick with the PyPi website though.
The pip command doesn't really give you very much information about those search results so it's just the package name and then a very brief description, which can be useful but as you've seen in the PyPi demo, oftentimes, a single keyword can lead to many search results so it's a little bit hard to untangle that from the command line if you only have limited information available.
Nevertheless, that feature exists and it can be useful in a pinch.

You just saw the PyPi package repository.
And while PyPi is the official package repository for Python right now, it is about to get superseded by Warehouse, which is going to be its successor.
So let's talk a little bit about Warehouse and how this transition is going to go.
So Warehouse is going to replace PyPi eventually, but right now, Warehouse is only running in a public beta testing mode.
The idea with transitioning PyPi to Warehouse is that ideally, you wouldn't have to worry about the transition at all, you would just use your pip commands as you did before, but instead of downloading files from PyPi, they would actually find and download packages from Warehouse.
Now, let's take a quick look at Warehouse.
Like I said, Warehouse is available for a public beta access right now, and you can find it at pypi.org.
Okay, so let's take a look at Warehouse, PyPi's successor.
So we get this banner here that tells us this is a beta version, or a pre production version of Warehouse, and eventually that warning is going to go away, as Warehouse takes over, and you can already see here the website looks a little bit more friendly than the classic PyPi, but in terms of functionality it is very similar.
So again, I am just going to search for Requests here, and in this time, you can see that the search results are actually a little bit better, so they look a lot nicer, and they seem to be more relevant, so in this case Warehouse seems to know that hey, there is a package called Requests and it is the most popular one so it actually is number one search result here, so let's take a look.
Again, you get a mixture of the readme or description for the package, and then a bunch of metadata, and it's just presented to you in a much more friendly way and there is also this little hint on how you would go about installing this package for example which is nice, and it looks like they also got the image formatting issue under control.
So now, all of the package metadata lives on the left here, so again, you pretty much have the same categories and the same information here, and then, when you scroll further down, we're back at the change log and stuff like that.
So, all the information is still in here, it's just presented in a different way, so Warehouse and PyPi are really similar, but Warehouse is just a more modern iteration and a more friendly version of what PyPi used to be.

Next, you'll learn how to install packages with pip.
We're going to cover the different ways you can install packages from PyPi, how you can install packages from other sources, like git and other version control mechanisms, how you can update packages and how you can uninstall them again.
This is how you install packages with the pip command line tool.
Basically, you open a terminal, and you run the pip install command, passing it the name of the package that you want to install.
And by default, this is going to install packages from the PyPi package repository.
Pip also caches packages locally, to speed up repeated installs.
Let's take a look at a quick demo here.
I am in a new terminal session here, and now I am going to walk you through how to install a Python package using the pip install command line.
So, the pip command line interface has a couple of useful commands, for example, there is the pip list command, that I can use to inspect which packages are installed at the moment, so let's run this.
So this lists all of the packages that are installed into my global Python environment right now, this is a really base line setup and it doesn't really include anything besides pip and its dependencies, what I am going to do now is install a third party package, and for that we're going to use the Requests module.
So when you look at this list, you can see that it definitely does not include Requests right now, so let's change that.
So this is the pip install command to install the Requests library, let's run it now.
Alright, so the installation completed successfully, and now when I run the pip list command again, Request should show up in that list.
Yeah, here it is, we successfully installed Requests.
Let's try it out, so I am going to jump into a Python interpreter session now, and I am going to try and import the Requests module that we just installed, alright, this succeeded, yeah, that looks pretty good, let's try and actually fire off a real HTTP request.
Perfect, that worked just fine.
Another handy command is pip show, you can use it to display metadata and information about locally installed packages, so I am going to go ahead and run that on Requests now.
So you can see here, for example, the name and the version of the library that was installed, a quick summary, the homepage for the library, the license and also where it was installed locally on my machine.
So you just saw how to install a package from PyPi using the pip install command, now what this will do is it will always install the latest version of the package that is currently available, so what do you do if you want to install an older, or a specific version of a package instead?
Pip has you covered there.
You can actually pass so called version specifiers to package names when you install them through pip install, with this pip install requests==2.1.3 command, I am installing a specific version of Requests and these version specifiers can get pretty flexible, for example, I can do this and actually pass a version range for this Requests module, so in this case, I would tell pip to install a version of Requests that is between version 2.0 and 3.0, so essentially, I would tell pip to install the latest version in the version 2 series of Requests.
One more feature when it comes to version specifiers, is the ~=specifier.
This tells pip to install a version of Requests that is compatible with version 2.1.3 in practical terms, that means it's going to try and install a version of the 2.1 branch of Requests, that is going to be at least version 2.1.3, so 2.1.4 and 2.1.5 and so on, would all be candidates for this.
Now this is handy for example if you want to get minor version updates automatically, but you still want to retain some control over larger upgrades, if you're using version specifiers, I would generally recommend that you are very specific with them because this can help avoid surprises.
Later on in this course, we're going to come back to these version specifiers, and you're going to learn how to use them to set up fully reproducible Python environments for your applications.
Before you move on, here is a quick warning about installing packages globally using pip.
When you use the pip install command, by default, it will install Python packages into the global Python environment.
This means that any package you install this way is going to be shared across the whole system or across your whole user account, now this might be completely okay, if it's done intentionally, for example, in order to install Python based command line tools, like httpy in this case, you probably want to make sure that you can access the tool from anywhere in the system.
Most of the time you should prefer so called virtual environments, they are a way to keep your Python packages nice and separate by project, and that way you can make sure you're not cluttering up the global environment, later on in this course, you are going to learn how to set up and use virtual environments, this will help you avoid version conflicts and we'll make sure that each project you're working on has its own Python environment, to install packages into.
Here is another useful feature for installing packages with pip.
You just learned how you can install packages from a package repository like PyPi, but pip also supports other sources, for example, you can install packages directly from git and other version control systems, here is what this would look like for installing a package that is hosted on GitHub, you would pass a url pointing to a git repository to the pip install command.
And you can even control which branch or a specific commit in that repository you want to install.
Here are a few examples that install the Requests library directly from GitHub.
In the first example, I am putting the at master specifier, to install the latest version of Requests directly from its master branch on git.
In the second example, I am using a commit hash specifier to install a very specific version of the Requests library.
In the third example, I am pointing pip at a specific git tag to install Requests from.
You can see here how this gives you a lot of flexibility, you might use this functionality to install a very specific versions of a library, for example, if you're waiting for a bug fix to land in the official release, and you really can't afford to wait so sometimes maybe you want to install the latest version of a library, directly from its source repository.
or, you could use this feature to install private packages and libraries that are not available on PyPi.
So you would just host your own library in a git repository somewhere, and then point pip towards that.
generally though, if you can install a package from a proper package repository like PyPi, then I would definitely do it.
Installing a Python package directly from a version control system is a bit of a special case.
Typically, you wouldn't use that functionality to install any old publicly available package, but you would reserve it for those special moments when you really need to be on the cutting edge and maybe need to install a specific commit of a package to get your program to work.
This is definitely useful but I would also handle it with care, and stick to PyPi when possible.

Another benefit of using a package manager is that you can keep your packages and dependencies up to date.
Pip can identify outdated packages that have new versions available and then also upgrade them to the latest version.
Let me show you how that works now.
I am going to set up some kind of demo scenario we can work with here.
So what I am going to do is I am going to install an older version of the Requests library so that we can then go ahead and upgrade it.
So I just installed Requests 2.0 which is an older version of Requests at this moment.
What I am going to do next is I am going to ask pip to identify outdated packages; you can do that with the familiar pip list command, and by adding a --outdated switch to it, so when I run this, it tells me exactly which packages that I have currently installed are outdated and what the latest version is.
So in this case, I can tell that there is a newer version of Requests available.
Now, let's upgrade Requests to the latest version.
Again, I am using the pip install command, but this time I am passing it a --upgrade switch.
And then I need to tell it which library to upgrade, so in this case, it will be Requests.
this will first uninstall the outdated version of Requests, and then install the latest version.
By the way, you could get the same results with the -u switch, so that is just a shortcut for a --upgrade if you want to save some typing.
Let's make sure we actually upgraded to the latest version of Requests.
I am going to run this pip list command with the --outdated switch again.
Alright, this time, there are no more outdated dependencies, and I just successfully upgraded Requests to the latest version.

What do you do if you've installed the Python package, but you want to uninstall it and completely remove it from your system?
For example, if you've installed a package just to try it out how do you undo that, how do you uninstall the package?
Let's talk about that now.
You can uninstall packages and remove them from your system using the pip uninstall command, this command is really similar to the pip install command, you just go pip uninstall and the name of the package and pip will remove the package from your system.
Here is a quick demo; you can see here that I've got the Requests package installed.
Let's remove it.
Once I triggered the uninstall command, pip is going to ask me if I really want to remove this package, so at this point I can still cancel the process, and no change will be made to my system, so I am going to go yes here, and hit return, alright, and that's it, you successfully uninstalled Requests.
Let's make sure it's actually gone.
As you can see, Requests no longer shows up in this list of installed packages.
You just saw how uninstalling a package through pip removed the package itself.
However, the question remains whether that also removes dependent packages, or in other words, will uninstalling a package also remove the secondary dependencies off this package, and the answer is no, so pip uninstall will not uninstall secondary dependencies, therefore, it isn't that easy to keep your Python environment nice and clean, this is why I recommend that you use virtual environments as much as possible, there is a whole section in this course dedicated to virtual environments, but in short, there are way for you to create new Python environments that are completely separate from your global environment, so you can install packages without cluttering up your global Python environment.
And if you're using virtual environments then removing packages and cleaning up all of the unneeded secondary dependencies is really easy, you just delete the virtual environment and recreate it from scratch.
And this will get rid of all the unneeded secondary dependencies.

Congratulations, you've just completed the managing third party dependencies with pip module in this course.
Let's review what you've learned.
So we started out by talking about dependency management what it is good for, what packages are and how they work in Python.
Next up, you learned about pip, the Python package manager.
After that, we made sure you've got the latest version of pip installed on your system.
Then you learned about Python package repositories like PyPi; after that, we were installing packages from the command line using the pip tool.
You also learned how to identify and update outdated packages on your system.
And last, you learned how to uninstall packages from your Python environment.
Here is some key takeaways for this module in the course.
Dependency management principles and package managers are key ingredients to modern software development.
They allow you to simply search and install well packaged third party building blocks that you can then use in your own programs.
A key tool for that is pip, Python's recommended package manager.
Generally, third party Python packages will be hosted on so called package repositories like PyPi.
Pip also has powerful version management features, they can help you keep your local packages up to date and under control.

In this part of the course, you'll learn how to isolate your Python dependencies using so called virtual environments.
Here is where you are right now in the course.
And this is what you are going to cover in the upcoming module in the course.
You are going to learn about virtual environments, what they are, how they work, and what they are good for.
Next, you are going to learn how to create and activate a virtual environment on your system, after that, you're going to learn how to install packages into a virtual environment; you'll also learn how to deactivate virtual environments and how to completely delete them again.
And last, I am going to show you some tips in my personal workflow that I use to make working with virtual environments a little bit more efficient.
Okay, ready?
Let's jump right in!
So we just learned that Python has a powerful package management system.
What do we need that isolation for?
The thing is that by default, pip installs all packages in a single shared environment, which means that if you need different versions of Python packages, there are going to be version conflicts.
Here is an example.
Imagine you are working on two projects.
Project one needs a specific version of Django, let's say version 1.8, and it also needs a specific version of the Requests library, let's say version 2.0.
Now, the other project, project 2, needs a completely different version of Django, and it also needs a different version of Requests.
Now if all of your packages need to be installed into the same shared environment, there are going to be version conflicts between these packages.
Another kind of version conflict you might face is that let's say you are working on one project that actually needs Python 2.7 to run, and all of your new development happens in Python 3.
So, maybe you're working on another project that actually requires Python 3.6 to run.
How do you resolve these version conflicts?
Virtual environments are really helpful tool that can help you with this problem, so a virtual environment allows you to isolate all of your Python dependencies by project, and this works for packages and also for different versions of the Python interpreter.
So you can think of these virtual environments as individual sandboxes for each project.

I am going to jump into a terminal session now, to show you how you can create and activate these virtual environments.
Alright, I'm in my terminal here and now I am going to show you how to create your first Python virtual environment.
So, the first thing I want to demonstrate to you is when I use the which command to look up where the pip executable is right now.
You can see here it's inside user local bin pip3, which is the global shared environment.
Now if I would go ahead and run pip install and install some library, it would end up, well, not exactly here in this folder, in the bin folder, but it would end up in the global environment.
So, the way around that is by creating a virtual Python environment.
Now let's assume we wanted to start a new Python project, so probably create its own folder for that, so I would create a directory let's call that test project, switch into that test project, and you can see here that right now, this is completely empty, so what I am going to do now is I am going to create a virtual environment, with this command here, so you want to go Python3 -m venv if you are on Python 3, on Python 2 it's a little bit different but I am going to walk you through that later, and then as the last argument here, you can pass the name of the folder where you want to store that virtual environment, or where you want that virtual environment to be created.
Now, personally, I use a very simple naming scheme, I just create my virtual environments right inside the project folder, and I usually call them venv.
So, personally, I would do something like this, but of course, you could also have a shared folder, like a Python environments folder, where all of your Python environments live and then you are going to be able to reuse them across different projects.
Now, personally, I don't recommend that, so this is what I like to do.
Okay, so this just took a second here to set up the virtual environment, and now, when I check what is inside this folder, we can see here that now we have this venv folder.
And when I check what is inside the venv folder, you can see here that there is a bunch of files that are part of this new Python environment.
Now why don't we take a closer look at this venv folder?
So you can see here that there is a lot of stuff inside that folder, because this is actually a completely isolated and separate Python environment.
Now this is not going to be very interesting, because, it's just the Python internals here, but this should give you an idea that a Python virtual environment is actually a completely separate Python environment, and that is exactly what we want.
Alright, so we created a virtual environment, and if I were to run this pip3 command, or the pip command now, it would actually still point to the global environment, so there is one more step we need to take here.
And that is we need to execute a script inside the virtual environment.
And, it's this one here, so inside the virtual environment, you want to go into the bin folder and look for the activate script.
And so when I run this, this activates the virtual environment, and you can see that here that running the script out of this little marker here to my shell prompt, now it tells me that I am inside, or that I have activated this virtual environment called venv.
So that is just a folder name that I used earlier.
Now, when I use this which pip command again, you can see that now this is actually pointing to a different location, so now this points to the separated and isolated environment that I just created.
And the same thing is true for the Python interpreter, so now if I were to run the Python interpreter, it would actually load it from inside the virtual environment and not from my global environment, which is exactly what we want.
So this is how you create and activate the Python virtual environment, so here is a quick recap on what I just showed you, so on Python 3.3 and above, it's really easy to manage your virtual environments because the venv command, or the venv module that manages them is actually part of the Python distribution, so you can just use that Python -m venv and then the name of the folder where you want to create that virtual environment.
But on older Python versions, it's a little bit different, so for those versions of Python, you typically need to install the virtual env package manually, and then you would use the virtualenv command and it would kind of follow the same syntax to actually create a virtual environment, and you would activate it in exactly the same way.
So that is a little difference you need to be aware of, maybe one extra step you need to take before you can start creating your virtual environments.
On Windows, the step you need to take to actually activate a virtual environment is slightly different, so we're not using the source command there, to load the activate script, but instead, we're just running the activate command or activate script from the scripts folder, so that is a small difference, but in all other aspects, it's very similar to how it works on Linux and macOS.

So next up, I am going to show you how to install packages into a virtual environment.
And for that, we're going to jump back into termianl session again.
So I am in the same project folder as before, and I am inside an activated virtual environment.
So what I am going to do now is I am going to use the pip command to install the popular Requests library.
Now, when I run the pip list command you can see here that I successfully installed this Requests package, and that the environment I am using here is pretty much empty besides that.
So there is some other stuff in here for example, the setup tools, module or the pip module, but these are really just part of the core Python install.
So, this is nice, this is exactly what we wanted, we're not cluttering up the global install here, and just to make sure this actually works, I am going to jump into a Python interpreter session I am going to go ahead and I am going to import the Requests module and I am going to fire off a simple http request Alright, so this worked just fine, so you just saw how to install a new module inside of the virtual environment, it's really similar to the way you would install a package inside the global environment, but the big difference this time is that everything is kept nice and separate and we're not cluttering up your global Python environment with this here.

Another important aspect that I would like to cover is how to leave a active virtual environment, and then also how to switch between different virtual environments.
So again, I am going to jump to the terminal for this.
Alright, so I am back in my example project, inside an active virtual environment.
Now, how do you get back to the global environment if you are inside an active virtual env?
And the answer for that is pretty easy, you just run the deactivate command.
So the deactivate command is available every time we're working in an active Python virtual environment, the global environment does not support this deactivate command.
Now you can see here that when I ran the deactivate command, it actually removed this little marker here, from my shell prompt, so now I can tell that I am back in the global environment.
One more thing I wanted to mention is how do you actually switch between different virtual environments if you are working with multiple projects so right now I am still in this virtual environment for my test project here, and what I am going to do here is I am going to leave that environment and then I am going to go to a different project folder that also has a virtual environment, and here, I would just use the same activate command to switch into that virtual environment and then start working from here.
And it's a good idea to deactivate or leave an active virtual environment before you go and activate or enter a new environment.

Now what do you do once you're done with the virtual environment, or you want to recreate it from scratch?
How do you get rid of them?
Because, if you're working with virtual environments over time, you are going to accumulate a couple of them, if you're creating one per project, and so what do you do when you want to get rid of these virtual environments to reclaim the space they take up?
I am going to show you how to do that now.
So we're going to delete an existing virtual environment here, so right now, I am in this test project folder, and I am inside and active virtual environment; so in order to delete this virtual environment, I would first of all deactivate the environment so that we're back in the global environment, and then all you need to do is delete this venv folder.
So, what I am going to do here is I am going to delete it using the rm command and you always want to be careful when you are running this command just as a word of warning, because you can easily delete a bunch of stuff that maybe you don't want to delete.
So it might be easier for you to actually go into a file manager and just to delete the venv folder there if you absolutely want to make sure nothing can go wrong.
But I am going to go ahead here and I am just going to delete this folder, and now you can see the project folder is empty or I actually deleted this venv folder, which means now the virtual environment is gone, it doesn't take up any space anymore and if I wanted to, I could recreate a virtual environment under the same name and then just repopulate again and configure it in the way I want.
So this is a great way to reset a virtual environment if something went wrong, you just wipe it out completely, delete it and then rebuild it from scratch.

There are a few command line tricks you can use to make your life easier when you're working with these virtual environments.
So I want to show you a quick walkthrough the virtualenv setup or the virtualenv workflow, that I use personally for working on Python projects.
So I am in a fresh terminal session here and let's pretend I want to work on a project called test project, the one we created earlier.
So the first thing I would do is to switch into the project folder, and then I have this alias command here in my shell that I called ae for activate, and I can use that to super quickly activate virtual environment without having to type out this source command.
So I am going to run this, and what this does is it's automatically activating the virtual environment because I use this naming convention, where I just call all of my virtual environments venv, so the command is just going to look for venv virtual environment, and it's going to activate it.
Next, I would do my actual work on the project, run my tests, work with the Python interpreter, run the actual project, and then when I am done with the project, I would just type de for the deactivate and that deactivates the virtual environment.
I am going to show you how these aliases work, in a minute.
There is one more thing I wanted to show you first though.
And that is how they allow me to quickly switch between different virtual environments.
So I am going to activate the virtual environment for test project again.
And now let's imagine I wanted to switch and work on a different project with its own virtual environment, so I am here now in the different project folder, and now I would need to switch to its new virtual environment.
And this project's virtual environment uses the same naming convention, so now I can just go ae again and what that is going to do, is it's going to deactivate the previous virtual environment and then activate the new one.
So I don't have to type deactivate first, and then of course, I could do my work and just deactivate the virtual environment again.
So I am using these ae and de shortcuts or aliases to make it a little bit easier to work with virtual environments from the command line.
And now I am going to show you how those work behind the scenes.
So what I have done here is I've modified the config file from my shell, I am using bash so this would be ~/.bash_profile And I've added these two lines here, that configure an ae and a de alias.
Here is what the ae alias does.
It tries to deactivate any virtual environments that I am already in, and then it sources the activate script in the local venv folder, so if I am using the same naming convention for my virtual environments, this will just work every single time I am working on a project.
And the de alias just points to deactivate which is going to save me some typing in the long run.
So the usage for this is really easy, I just switch to a project folder, I punch in ae, hit return, then I can work on the project and when I am done, I just type de and I leave the virtual environment.
And this makes working with virtual environments just a little bit smoother so this is something you could try out and see if you want to incorporate that into your own workflow.

Congratulations on completing the virtual environments module in the course.
Here is what you covered.
You learned what virtual environments are, you learned how to create and activate them, you learned how to install packages into a virtual environment.
And you've also learned how to deactivate and even destroy a virtual environment.
And last, I showed you some tricks on how you can optimize your virtual environment workflow and make it a little bit more efficient.
In the last few lectures you learned about virtual environments and how they can help you keep your project dependencies under control.
Virtual environments help keep your project dependencies isolated so that you can avoid version conflicts between packages and different versions of the Python runtime.
So in a nutshell, a virtual environment allows you to use different versions of the same package, and different versions of Python depending on a project that you're working on.
And as a best practice, all of your Python projects should use virtual environments to store their dependencies.

Welcome to the finding quality Python packages module in the course.
One of my favorite things in Python is the rich third party package ecosystem.
There is so many open source packages available that you can just install for free and use in your own applications.
The ability to find and identify these high quality packages will make you a much more productive and effective Python developer, but first, let's take a quick look at where you are right now in the course curriculum; at this point you have all the tools you need to be able to install third party packages, and to keep them nice and separate.
So now you're going learn where to find these high quality packages you can use in your own applications.
Here is what this module in the course will teach you to do, first, you're going to find out how third party packages can help you become a more effective and more productive Python coder.
Next, I am going to show you several curated lists of the most popular Python packages and you can use those lists to quickly find the best options in a specific category, for example, the most popular web frameworks in Python.
After that, you are going to learn a specific workflow and some rules of thumb and quality indicators for selecting a great quality package.

Let's talk about how third party packages can help you become a more productive and more effective Python coder.
What I absolutely love about Python is the fact that it has a super rich third party package ecosystem.
When I check PyPi, close to 100 thousand packages which is freely available for anyone to install through pip.
And all of these modules and libraries combined cover a wide range of topics and scenarios.
Because of this rich third party library ecosystem it's fairly likely that whatever scenario you encounter, there might just be a free Python library that you could use that will make your job so much easier.
Imagine you're working on a Python project, and now the need arises to download files over http or to talk to some kind of web service in your application.
Now of course you could go in and write this functionality from scratch, but maybe just maybe, there is a third party package that could help you with this.
And if you found the perfect third party package, you could save a lot of time, you wouldn't have to reinvent the wheel, and write this stuff from scratch, and you could deliver the whole project so much faster.
Where do you find those great Python packages?
And this is a very common question, and the common challenge for every Python developer, leaving the safe haven of the Python standard library.
So given a problem that you want to solve in your program, how can you identify and where can you find a package that could help you with that?
Then of course the next question is what actually makes a quality Python package, how can you tell if you have multiple options available, which one is better, which one is going to have less of a maintenance burden and which one is the safer choice in the long run.
Unfortunately, I'll have to share some bad news with you first.
There isn't really a shortcut to finding the perfect Python package, because there is so many packages you can choose from, it will always take some research and some elbow grease to find the perfect package or the perfect library given the situation that you are in.
However, this is totally worth it, this is a perfect way for you to really scale your productivity and take it to the next level.
If you can develop the skills to find and identify quality third party packages, and you can start leveraging those in your own programs, your productivity will shoot through the roof.
Because you will be able to avoid having to reinvent the wheel all the time, and you will be able to build your applications using these freely available building blocks and that will make you much faster, much more effective and much more productive as a Python developer.

Browsing through curated lists is one of the quickest ways you can find a Python package that can help you with a problem at hand.
So you can just pull up one of these curated lists websites and then browse popular libraries by topic.
For example, one topic might be web development, another one might be database interfaces or data science.
And that gives you a good idea of what the popular and recommended choices for solving those problems are in the Python community.
I've listed some of these curated list websites for you and we're going to take a look at a couple of those now.
The first curated list website that I want to show you is called Awesome Python, you can find it at awesome-Python.com This is a really extensive list with useful Python packages.
You can see here, it's split up into different categories and then you can drill down into those.
Let's check out database drivers here.
now you can see here that there are actually subcategories for example, the drivers for MySQL, Postgres, and so on.
Now this isn't a review site, this is nearly a list of popular packages so you will still have to make a decision which one you prefer and I am going to give you some tips for that, later on in the course.
You can also search this list, which is handy sometimes, so for example if you're looking for libraries to download stuff through http you can find those quickly through the search function.
Now what's interesting about Awesome Python too is that it's an open source website, there is a community of people working on the website contents through GitHub.
And you can see ongoing development here on the GitHub project page, people will create issues and pull requests to add new recommended libraries or change the preferred choice.
So all of this is very fluid, and the great thing is that it's usually fairly up to date.
So what I really like about this curated list is that there is so much activity and people are working hard to keep it up to date.
Also, you can contribute and jump in and help make the site better if you want to.
Another useful website is Python.libhunt.com, the packages that show up here are actually based on the contents of the Awesome Python list.
But libhunt adds some extra features on top of that, for example, more extensive search and then they also have some metrics for project health and popularity which can be helpful sometimes.
For example, there is this relative popularity indicator, that might be helpful for you to make a choice between two libraries, there is also this activity indicator telling you how much activity there is on the project repository.
Again, this can be a good way to identify a well maintained package, now when I click on one of those packages, I get some more stats here instead of just being redirected to the project homepage.
Depending on what you're looking for, this Python.libhunt website might be a good way for you to find quality Python packages.
The Hitchhiker's Guide To Python is another great website with library recommendations.
You can find it at Python-guide.org When you scroll down a little bit, you will find the scenario guide for Python applications, and this guide makes some recommendations around tools and modules based on different scenarios.
Let's check out this network application section here.
We see a list of recommended libraries here and while this is not as extensive as Awesome Python what I like about this is that it gives a little bit more background info about the library.
This might save you some research time, and in general, the Hitchhiker's Guide To Python is a pretty fantastic website, so you might want to check it out in any case.
Again, this guide is an open source website on GitHub, so people can contribute to the site through issues and by opening pull requests and that generally means that there is some activity and it's kept up to date over time.
Another handy website is Python Module Of The Week, you can find it at pymotw.com Now, this website is mainly focused on modules in the Python standard library, it's not really reviewing any third party modules but nevertheless, this is a great resource to find some of the awesome packages that are shipping with Python and that are included in the standard library.
One of the great things about Python is that it comes with "batteries included", you will be able to solve many of the problems you encounter in practice by working with the Python standard library; generally the implementations there are well maintained, and they are included with any Python install, so it makes sense to do a quick check if what you are looking for is already part of the Python standard library, and for that kind of research, Python Module Of The Week is a great website.
Okay, here is one more useful website for doing that kind of library research.
Python has an official wiki at wiki.Python.org and it also includes some library recommendations or generally useful libraries that you might want to check out.
There is a useful modules page in the wiki and it will point you to some of the building blocks that you can use in your own projects, let's check it out.
Again, this is organized by category and while I found this isn't as well maintained as let's say Awesome Python there is still some interesting modules in here, so if you have the time to do research you might want to check out the wiki as well.
Some of these sections have specific pages that talk about web programming for example, so you also might want to check those out.
The page on web frameworks for example is pretty extensive, it's kept fairly up to date and there is a big list of Python web frameworks that you might want to browse through if that is what you're interested in.
Personally, I would probably start my research with one of the other websites, but it might still pay off to spend some time browsing around on the official Python wiki.

When you're looking to find a quality Python package to help you out with a problem at hand, it can be a little bit overwhelming, having to select between all of these different options.
In my time as a Python developer, I've come up with a series of rules of thumb for selecting a great package.
I've turned this into a seven step workflow that you can use to find and select quality Python packages.
Let me walk you through it now, step by step.
Think of this workflow as a funnel.
First, you're going to find a poll of candidate packages, and just do a bunch of research and basically collect as many packages as possible that could help you with the problem at hand, and then, with each of the steps in this workflow, we're going to successively refine this list by excluding packages, each step will help you gather more information and give you a better understanding of the quality of each package.
The goal of this process is to make the decision which package to use, really really simple.
You'll be starting with this long list of candidate packages and in the beginning, it will be almost impossible to tell which one is the perfect package for your use case, but as you keep narrowing down that list, by the end of this workflow, you will have narrowed down that candidate list so much and you will have built a great understanding of the strength and weaknesses of each library, that making that decision is going to be very easy for you.
The ability to find and identify great Python packages, is very helpful even if you're working on your own, but it gets so much more powerful if you have to justify your dependency decisions to a team of other developers or to your manager.
You can apply the same workflow and the same criteria and use them to explain your decisions; to give you a concrete example, you could just take this process and as you go through it, take extensive notes and basically compile a report about your decision and after you went through those seven steps in the workflow, this is going to be a pretty bulletproof report that you can then share with your team, or your manager.
Alright, let's jump right in and then you'll learn this important skill in no time.
Let's start with step 1- finding candidate packages.
The first thing that I usually do is that I come up with a list of candidate packages that will help me solve the problem at hand.
And there is a number of ways you can fill up that list.
In my mind, it really helps to come up with the series of options, so that you have a base for comparison.
Now, let's talk about how you would fill up that candidate package list.
I often start out by browsing through the curated lists I told you about earlier, so I would just open up those websites like Awesome Python, I will try and find the matching category that is relevant to my problem that I am trying to solve and then I'll just click through that category checking out all the packages that are listed there.
Another option would be just to run a quick Google search for two to five relevant keywords, imagine you are looking for a way to upload files to Amazon's S3 service using Python.
Here is what I would do, so for that, I just open up Google and then I would probably search for something like S3 upload Python, you know, very focused keywords and just kind of sprinkle the minimal set of keywords that I could think about, and I just search for that.
And then the results here are going to give me a pretty good overview, so I probably just click through the first three results or so, and just check out what they have to say.
Now, this question here, pretty much is what I had in mind and looking at the first answer points me to the boto library, so I'll probably check that out and add it to the list, and then I do the same thing for the other top search results, now in this case, I know from personal experience that boto is a great choice, so the fact that we're already seeing this result is a pretty good sign.
Honestly, I found that a quick Google search can really help you out here, it's often digging up the right content immediately pointing you to results on Stack Overflow or on forums like Reddit or Hacker News.
So I usually do that really early on in my research process, when I am looking for a new Python package.
You've already seen that I looked at a Stack Overflow result here, so Stack Overflow is another great site you can use to find recommendations for Python packages, if you haven't used Stack Overflow before, it's basically a question answer site for developers.
And you can search it as well, so I am just going to punch in the same keywords that I previously searched on Google, just to see what comes up, so by default, this will be sorted by relevance, which is kind of an opaque measure, so often, I'll just immediately switch over to the votes tab which will give me the most upvoted answers.
Alright, so let's check out the first answer here.
So, this is the number one upvoted answer for this question, I am not going in to read the full question, I just want to see what kinds of libraries and tools people recommend here.
And as I scroll down, I can immediately see that okay, boto is another library that people recommend, so again, this will be a pretty good indicator that I should really check out this boto library because it just keeps popping up again and again.
Another great recommendation for finding quality Python packages are community forums like Reddit or Hacker News, and sometimes you can also use Twitter like that, let's take a look at those now.
Reddit is a community forum website that has a pretty large Python community, you can find it at reddit.com/r/Python And reddit has a search feature as well, again, what I would do here is I would punch in the same keywords and then I would limit my search.
In this case, we could probably drop the Python because we're just searching the Python forum.
So, anything S3 related will pretty much be about Python.
Alright, let's see what we got here, so this looks pretty helpful already, one interesting bit here is that you can see when the question was submitted, or when the form thread was created.
So you want to make sure you are not looking at super old content for things that could change frequently.
But let's just check out this discussion here.
So this looks like this is not going to give me the answer immediately, but I can still learn a lot about how people talk about the problem here, what keywords they use and that could point me in the right direction to actually find the library that does what I want or I actually find a discussion where someone recommends a specific library and then other people can respond to that discussion and I can read what they have to say and that is going to give me a pretty good idea of whether or not that library might be the right choice for me.
Another helpful community forum is Hacker News.
Now, by default Hacker News doesn't have a search function built in, but you can use a third party search at hn.algolia.com that can do a full tech search on comments and stories inside hacker news.
Again, let's punch in S3 upload Python and see what happens.
Alright, so looking at these results again I see boto popping up here so this could be interesting, maybe this result is a little bit old, but again, this could be a good way to fill up that candidate list and identify libraries that other people recommend and use.
Even if you're not using Twitter, just the fact that so many people share their thoughts on Twitter all the time, can be pretty powerful if you're looking for an answer to your programming question, I know it sounds a little bit crazy but this works more often than you'd think, so let's try it out, I don't know what is going to happen.
Again, I am searching for the same set of keywords, and then I am just going to check out some of the responses here, alright, so sometimes it's going to reference other source material like Stack Overflow, or blog posts, okay, so this looks pretty interesting here, this guy is talking about a script that uploads stuff to S3, so why don't we check it out.
So just looking at the code here, it looks like this guy is not using a specific library to talk to S3, but he is using the command line tool, this aws s3 command, so this could be another option for us to research now, maybe it's a good choice, I don't know, I know this process is a little bit time consuming but it's really impressive what this process can dig up.
If you do this for an hour or two, you're going to be pretty much an expert on what's out there in terms of libraries that could help you with this job.
If you've searched all these sites and you're still not happy with this candidate package list that you've built up, then it might make sense to search PyPi directly, personally, I find it a little bit hard to find stuff on PyPi because the interface is pretty clunky, and there is very little curation.
But it might still make sense to spend a few minutes on that and see if you can dig up something useful.
Now, another option to get those candidate packages would be to actually ask a question on Stack Overflow or Reddit, so on all of these sites you can create a free account, and just start asking questions, of course, you want to be mindful of questions that people have asked in the past, so I recommend that you do some research first to avoid running the danger of posting duplicate questions.
But usually, people are pretty receptive and helpful on these forums, so it might make sense to give it a shot.
However, it's rather time intensive to write and post the question and then having to wait a couple of hours or even days to get a response.
Now at the end of step one, you should have a list of candidate packages that you want to do some further research on.
After you've generated a list of candidate packages, the next step is to check out how popular these packages are.
Usually popularity is a good sign if you're looking for a Python package because that often means that the package is well maintained it's high quality, and you can't really go wrong with installing it and using it for your own purposes.
Now, how can you find out if a package is popular?
One way to do it would be to check out the download stats, now you used to be able just to go to PyPi and checkout the download stats for a package, but this feature was removed when the PyPi architecture changed.
So right now, you can't really get those stats, they might come back in the future, and then I think they are really good indicator, but right now, we'll have to go with something else.
Another good popularity indicator would be just the number of Google results and Reddit results and Stack Overflow results or recommendations you find for a given package.
And often, this step of the research process happens in combination with the first one, so as you go along and search these sites, you can take mental notes of which packages show up frequently.
And this could be really valuable information, when you have to make a decision which one you are going to use.
If a package is hosted on GitHub, you could also check out their GitHub page and see how many stars they have on GitHub, so the star system on GitHub is a pretty simple voting system where people can favorite or star repositories.
Now, if you are thinking about installing a library that has let's say 5 thousand or 10 thousand stars, it's pretty much a no brainer.
If it only has 10 or 20 then maybe that is not a bad sign, but it's also probably not a super popular library.
Another way to get at that information is using the Python.libhunt website and it includes a popularity indicator that is based on some other opaque values sometimes it can be helpful to compare two packages and just kind of see which one has more traction.
Now at the end of step two, you should have a pretty good understanding of the relative popularity of your candidate packages.
Once you have narrowed down the list of candidate packages I would start checking out the actual project homepages.
You could learn a lot from a project website, things like does this website actually feel helpful, is it answering my questions that I have as a new user, does the website look actively maintained, and how successful does this project look, did someone actually spend the time to make the website helpful and nice; let's play through this with an actual Python project website.
A great example here is the Requests library, and right away when this site loads up, this looks like a really high quality library, it has its own logo here, it looks like it's supporting a bunch of Python versions it looks like it has automated tests which is always a great thing to see, and the project maintainer is also tracking test code coverage.
Here on the left you can see that the page has this embedded GitHub stars indicator, and as you can tell, the library has a high number of stars here which is usually a good sign.
What I like here as well is that the page starts with a concrete example of what you can do with the library and what it looks like to use it.
This is great, so they even have a bunch of user testimonials from really well known people in the Python community, and when I scroll down further, I can see here that it has a pretty extensive user guide that covers a number of interesting things and seems really well structured, there is also in depth API documentation which is always a good sign.
Another sign that this is a really popular and strong library is that it has a contributor guide with all kinds of information about how to contribute to the project, the code style they use, how people should report bugs, and a really small and unpopular library is usually not going to have a need for that.
So when you see something like that, that is usually a strong sign that the library is really popular and very successful.
And by extension that means it's usually a safe choice for you to use that library in your own programs.
By the way, if you're wondering where to find a project's homepage, if it has one, you can usually find the link on PyPi, so it we'll be right here on the left and for older versions of PyPi you will typically have to scroll all the way down and then you can find the link to the project homepage there.
There we go, this is the homepage link for the Requests library.
At the end of step 3, after you check the couple of project homepages, your list should have narrowed down a little bit further, at this point you are starting to get to know these projects a lot better and you have a good idea of how popular they are, how well maintained they are, and whether or not you like them.
So maybe you can already start excluding some libraries that you are not really enjoying as much.
Of course, not all libraries are going to have a dedicated website or homepage, that doesn't automatically mean that the library is not great quality, many Python projects don't actually have dedicated homepages, but if there is one, it absolutely makes sense to check it out.

Not all Python packages are going to have a dedicated project homepage.
But what every project should have is some form of README file, that introduces you to the project.
So I always check those too.
And what I like to see here, is that I want the README to cover the basics of the project, what does the library do, and how do I install it.
You could learn a lot about the quality of a library, by looking at how the maintainers communicate the value that the library provides, I also want to know what license the project is under, because that could really influence in what circumstances you can actually use the project and then, it makes sense to quickly check who the author is, is it a group of people, is it a company, is it an individual contributor, what have they done in the past, and do they seem trustworthy?
Let's take a look at a real project README now.
Alright, I am going to try and find the README file for the Reqests library now.
So, typically, what you'd be looking for is a link to the project source repository so it already looks like this is hosted on GitHub here, so I am just going to look for a link.
Alright, there we go, requests at GitHub, so that should be the link to the GitHub project where we can check out the project README, yes, this is it, so when I scroll down this is where GitHub displays the README file, and for other source control websites like Bitbucket, they will either display the readme in the same fashion or you can view it by finding the README file and then clicking directly on that.
Now the first thing that I can see here is that this looks really similar to the project homepage which isn't a bad thing, I mean, this contains all of the information that I wanted to get out of the README and it looks like it's really well structured and nicely formatted.
So this is great, this tells me how to install the library, and it looks really simple, it's pointing me to the documentation and it also tells me how to contribute to the project.
If you're wondering what should go into a great README file, I wrote this article a while ago, about how you can write a great README for a github project, I am covering a number of things here that in my opinion should go into a great README, for example, it should talk about what the project actually does, how to install it, some example usage, how someone could set up a development environment, some link to a change log, and then also license and author info, you can check out the full article in the link that you see here.
Now let's go back to the Requests README.
I said that I'd like to know under which license a library was published, so let's find that out now.
Usually where you can find that information is in a license file, at the root of the repository.
So this tells us that Requests is under the Apache license, a popular open source license; if you're wondering what the most common open source licenses are, and what their terms are there is a really great website you should check out.
Go to choosealicence.com/licenses and they have great simple and human readable explanations of the conditions and permissions and limitations in the most popular open source licenses.
So for example, this is the Apache license used by Requests, and this gives us a quick overview over the terms of the license, without actually having to drill down into the nitty gritty details.
Another thing that I'd like to know is who the authors are, who wrote a library.
Now, typically, in an open source library, you can find an AUTHORS file that will list all the contributors, again here with Requests you can get a really quick overview of who the core maintainers are, and then there was apparently a whole bunch of people who have submitted patches over time, and this is a great sign because it means you have a project leadership and then you also have a large group of people who are dedicating patches and contributions to the project.
We could also check out the GitHub user account that hosts the Request library, and in this case, it's Kenneth Reitz and you can see that Kenneth has a number of very popular libraries in the Python space, he is working for respectable and well known company and these are all indicators that Requests is a really great library.
At the end of step 4, maybe the field has narrowed down a little bit further, every Python library should have a good project README, and I find it helpful to familiarize myself with the licensing terms for the project, and the team of people working on or maintaining the library.
In step 5, you're going to make sure that the project is actively maintained.
In my mind, this is one of the most important quality indicators, now how can you find out if a project is under active development, usually a great way to find that information is to check out the project changelog and the update history.
You could either do that directly on PyPi or by checking the project source repository, also on the source repository you can usually find a bug tracker for the project.
Now this can tell you a lot about how the project is being maintained.
Are there discussions going on, are there many open tickets for severe bugs?
If there are no tickets, than that is usually not a great sign either, because in my experience, any project that gets some traction, has a flood of bug reports coming in; now I would recommend that you skim through some of those bug reports, just to make sure that there isn't some large problem with the project that would affect your ability to use it properly.
Another piece of information you can find directly on the source repository is when the last commit to the project happened.
Now you don't want to discount projects that do not have a lot of development activity going on at the moment, I'd rather pick a well seasoned project that is also well maintained or at least not abandoned over one that's super maintained but also brand new, because then you don't really know what the future holds, maybe the project is going to get abandoned in a few months, and then you're stuck with it, whereas a seasoned library that still does its job properly but it's not getting a lot of feature updates, could still be totally worth your while, there is nothing wrong with an older library that does its job really well.
At the end of step 5, your list of candidates projects will likely have narrowed down further and this is a good thing, the more projects you can weed out, the easier it will be to pick the perfect library for your usecase.
You are almost done here.
In step 6, you would spot check the source code of the project.
I always like to look under the hood of a library that I am going to use in my own programs.
And usually, this is really easy to do if you're dealing with an open source project, you just open the project repository website and browse around in the code a little bit.
Here is what I like to see.
Does the code follow community best practices, for example, does it have a consistent formatting style, are there comments in the code, are there docstrings, stuff like that, another hugely important topic for me is whether or not the code has automated test coverage, in my mind, a good quality Python package will always have an automated test suite.
Looking at the code will also give you a good idea of how experienced the developers were who wrote the library; often you can tell at a glance whether it was someone who had a deep understanding of Python who wrote a library, or if it was someone who was maybe coming from an entirely different language background and was just kind of told to write a Python library.
Now, this doesn't automatically mean disaster, but it's still a really good quality indicator.
In the end, it all boils down to the question would you feel comfortable making small changes to this library if you had to?
Because that is what the worst case scenario is.
Imagine you are building a really successful application that is using a particular library and then the original authors of the library stop maintaining it.
Well, if you don't want to give up your project, it will pretty much come down to you maintaining this library, at least enough so you can use it for your own purposes.
This is something that I always try to keep in the back of my head when I make a decision whether to use one library or another.
Alright, let's take a look at what this looks like in practice.
So I am back here looking at the GitHub repository for the Requests library.
And that gives me a really easy way to browse through the library source code, so I don't even have to install it, I can just use the GitHub code viewer and browse around and I don't need to pull this over into my own editor.
So what I would do here is try and find the main directory where all the source files live in, and in this case, it's the requests folder so typically this would be named after the library, and you can see here there is a bunch of Python files in there.
This seems pretty well structured already and you can also see there is a lot of activity here so these are being updated all the time.
Now let's check out one of those files.
For example, the cookies.py file, that sounds tasty.
And I would just spend some time reading that code, so things that I immediately like here is that there is docstrings, the imports are nicely formatted, you can see here the classes seem like they are named properly, again, there are extensive docstrings for everything, this class here with these methods on it, they seem well structured, right, there is not this crazy long like a thousand lines methods here.
This is all pretty nice and tidy and when I scroll further through the file, it all just seems like it's following a structure and it's formatted in the way that makes it easy on the eyes, and that is usually a really good sign, like imagine you have to maintain this code, personally I would much rather work with code that looks like this, than some convoluted mess.
And you can see here it seems to adhere to the PEP 8 formatting style which I think is also a good sign because if you are also using PEP 8 or something similar, than this library code is going to look similar to your application code, which also helps maintenance.
Yeah, so I would say this looks pretty good, let's see if we can find some tests.
Okay, so there is a tests folder here, and again, it looks like there are whole bunch of tests here, so let's check out the test_structures, alright, so they are using pytest which is a library that personally I like a lot so this would be a good sign for me, first of all I love the fact they have an automated test suite here and just glancing over those tests, I mean, they seem pretty reasonable, right, they seem like they are actually testing stuff, they are not just placeholders or dummy tests they are actually doing some things.
Now, usually I wouldn't do like a full code review for a library that I want to use, but I just want to do some spot checking to get an idea of the code quality for that library, because, in the worst case scenario I might actually have to do some maintenance work on this library, if someone stops maintaining it and it's an important part of my own application, then I would be pretty much responsible for keeping this thing alive so that I can continue to use it.
So this is always something that is in the back of my head; of course, Requests here passes that test with flying colors, and seeing how popular that library is, it's probably going to be maintained for a really long time so I wouldn't be too worried about this, but, of course it helps that it has great code quality too.
Okay you made it all the way to step 7, and this is the last step in this workflow.
So at this point, you would have a much narrow down list of candidates, and now it's time to try out a few of them.
So at this point, I would go over my notes and my memories, and take this narrow down list of candidates and just start installing some of them to try them out, in an interpreter session, and I am always suing a fresh virtual environment for that so that I am not cluttering up my system.
I would encourage you to do the same, and then you can just launch into an interpreter session, import the library, and play with it a little bit.
Or you might write a couple of small programs just to get a feel for how the library works, so for example, with Requests, maybe I would write a little program that downloads a file over HTTP and then I would try and implement the same example with a different library to get a feel for what the strength and weaknesses are of each of them.
Now actually, installing the library and then trying it out is going to tell you something very important; it's going to tell you whether the package installs and imports cleanly, because, at the end of the day that is super important, even if you have the best library for your purpose and it's so painful to install or it doesn't work on your system, then that is not going to help you.
So I always make sure to actually get some hands on experience with my top 3 choices or so, so that I can be confident into decision that I make.
Another very important question is whether or not you enjoy working with the package.
I strongly believe that developers should use tools that they enjoy working with, and this also applies to third party packages and modules and libraries.
So for me, this would always factor into the decision, now I realize that there might be business constraints and sometimes you just have to work with something that you are not enjoying as much.
But if there is a way to get the best of both worlds, a really great library that is actually fun to work with, I would always pick the one that is fun to work with and gets the job done.

Great, now you know all the steps necessary to find and pick a great Python library.
Let's do a quick recap.
So in step 1, we talked about how to find candidate packages, how to search them on various websites and sources.
Then in step 2, we check package popularity, to get a feel for how popular this library is in the Python community and how many people are using it.
In step 3, we check out the project homepage as another important quality indicator.
In step 4, we had a look at the project README, step 5 answered the question whether or not the project is actively maintained, then after that, in step 6, we spot check the source code to get a good feel for the code quality of this library.
And all the way at the end, in step 7, we took that narrow down list of candidate libraries and tried them out, to get a good feel for what their strengths and weaknesses are.
Again, this whole process works like a funnel, so you start with a pool of candidate packages, and then successively refine that list by excluding packages that you don't like or that can't actually get the job done.
So this is a process of narrowing it down until it becomes very easy to make the final decision.
Being able to find and pick great Python libraries for use in your own projects is a super helpful skill.
Now this is already a very useful skill if you're building software for yourself, but if you're working with a team and you have to justify these dependency decisions, then you can use the same process and the same criteria to explain your decision to your team, your manager or whoever is interested and basically write a little report on all of the options that you've tried out.
And after going through all of these research steps this report is going to be pretty bullet proof.
Congratulations, you just completed the finding quality Python packages module in this course.
Here is what you've learned.
First, we discussed how third party packages can help you become a more effective and more productive Python coder.
Next, you learned how to find popular packages on curated lists.
And third, you learned a whole workflow for selecting great quality packages and a set of rules of thumb for making the right decision.
Let's end this module with a quick summary.
Python has a super rich third party library ecosystem and using it effectively is the key to becoming more productive as a developer.
Now while it is great that you have so many third party packages available, using a third party package in your own programs, always has a maintenance cost, and this is something you should be very mindful of, the solution here is to stick to high quality packages in order to keep those maintenance costs under control.

Welcome to the setting up reproducible environments and application deploys module.
Here is where you are right now in the course, so you've learned how to manage third party dependencies with pip, you know how to isolate your dependencies with virtual environments and you also just learned how to find and identify quality Python packages, now let's talk about another very important topic when it comes to dependency management in Python.
Let's say you're working on a Python program, and the project has matured quite a bit, and so now finally, you want to share it with other people.
If you're using third party packages, in your Python program, then that might not be so easy.
How can you make sure that someone else trying out your program can get the exact same set of dependencies?
Even the slightest version conflicts can make installing someone else's Python program a very frustrating experience.
So the real question here is how do you reliably specify all of the dependencies that a Python program needs.
And this is not only about sharing your programs with other people, there are many environments your Python program can run in, for example, there is likely going to be a local development environment and ideally, that development environment should be the same across all of the developers working on the project.
Then there might be automated tests that are being run on a continuous integration infrastructure.
Again, all of these tests should run under the same set of dependencies, depending on the complexity of your program, there might be several deployment targets, for example, if you're building a web application, there might be a staging server and a production server.
How can you make sure that all of those environments use the exact same set of dependencies, because using the same set of dependencies across all of these environments, with the exact same packages and the exact same version numbers, is very important to achieve a reliable deployment process.
So really, the goal here is that all environments are going to use the same set of dependencies.
So this is the goal that we're aiming for here.
Now, how do you make dependency installs repeatable in Python?
And the answer is requirements files.
In this module in the course you are going to learn how to use requirements files to make your application deploys and Python project installs fully repeatable.
First, you are going to go through a quick introduction to requirements files, to learn what they are, what they look like and how to use them.
Right after that, you are going to learn how to capture project dependencies automatically using pip.
In the third lesson in this module, you are going to learn how to restore captured dependencies in order to deploy your application.
Next, you're going to learn some tricks on how to separate your development and production dependencies; to conclude the module, you are going to learn some best practices around requirements files that will make working with them a lot easier.
Alright, time to make your Python application deploys fully repeatable, let's jump right in.

You might have seen those requirements files before, they are usually called requirements.txt or sometimes also requirements.pip and what they are is basically a list of pip install arguments placed in a text file.
So this is what a very simple requirements.txt file would look like.
You can see here that the requirements file contains a list of package names.
So in this case, it includes the requests module, with a specific version using the version specifier syntax you learned about earlier, and it also lists the schedule module with a similar version specifier.
Now this is a very simple example but it's also quite typical of what a real world requirements file would look like.
One interesting thing you can do with these requirements files is that you can add comments to these files, so you would just place the hash character and then you can place a comment.
This is often helpful to explain what is going on in your requirements files or if you want to leave a comment for the next developer working on that file.
Requirements files capture all of the third party dependencies a Python program needs to run, and usually, they do that by specifying the exact package versions.
Using requirements files a Python environment can be reproduced in exactly the same way on a different machine or for different developer, or even just in a different directory on your local machine.
They are a key piece for achieving repeatability in your Python built environments.

Now how do you create one of those requirements files?
One way to do it would be to just create a text file, and type your dependencies into it.
And that might be a pretty good way to do it.
On the other hand, it becomes very difficult to actually capture all of the dependencies, including the secondary or transitive dependencies for you application.
Luckily, pip can help you with that.
So what I am going to do now is I am going to show you the pip freeze command you can use to create requirements files very easily.
I am in my terminal here and I've got a virtual environment activated.
So to show you that this is a completely new virtual environment where I haven't installed any third party dependencies, I am going to run the pip list command.
You can see here that this just contains the internals for pip and there are no third party packages here.
pip freeze is the magic incantation for creating these requirements files.
Now watch what happens when I run pip freeze on a virtual environment without third party packages.
That is right, nothing happens.
Because there is nothing for pip to freeze.
So now I am going to install a couple of third party packages so we can actually start creating a requirements file.
Alright, I just installed the latest version of Requests and now, when I run pip list again, you can see here that Requests shows up in this list, now we could just take that and type it out into a separate requirements.txt file but really this is what the pip freeze command is made for.
So when I run the pip freeze command now, I get a different result, it actually captured the Requests library as a third party dependency, so the output of the pip freeze command is all we need to create our requirements.txt file.
We can actually just take that output and pipe it into a requirements.txt file, and we don't even need to copy paste it and go through a separate editor, let me show you how that works.
So this is the command I would run here, and once that finished, it created a new requirements.txt file.
So when I take a look at this file you can see that it contains exactly the output of the pip freeze command, and that is a very quick way to capture the dependencies that are installed in your virtual environment or in any Python environment for that matter.
Now before we move on, I want to show you how pip freeze, not only captures the top level dependencies, but it actually is smart enough to go and capture all of the secondary or so called transitive dependencies, to include them in its output which we could then put into requirements.txt file.
So Requests doesn't actually have any third party dependencies, so it doesn't really make a great example here, so now I am going to install the Flask module, as another third party dependency because Flask actually contains a bunch of secondary dependencies that I can then use to demo how pip freeze deals with them.
Okay, so I just installed Flask here and you can already see that it came with a bunch of third party dependencies, and now these should actually show up if I run pip freeze again, as secondary or transitive dependencies, alright, so there we go, when I run pip freeze again, with Flask installed, it's also listing the other dependencies or the secondary dependencies that Flask brought with it, because really all I did here initially was run pip install Flask and then Flask itself brought in all of these other secondary dependencies.
Capturing these secondary dependencies is super important to make an environment reproducible.
As you can see here, pip freeze does exactly that, so if I regenerate my requirements file, you can see that this captures all of the dependencies, so with this requirements file, we're in a pretty good shape to completely reproduce this exact environment on another machine including the exact version specifiers and including all of the dependencies and secondary dependencies that our application might need.
Here is a quick recap on capturing dependencies using the pip freeze command, basically you'll run the pip freeze command and then take its output to create your requirements.txt file, and then you would include the requirements file with your project so that another developer can recreate the exact same environment that you were using at the time when you created the pip freeze file.
Please note that the requirements file only specifies third party packages and their version numbers, so this is not going to specify exactly which version of the Python interpreter to use for example.
pip freeze is the most important ingredient for achieving repeatability, so with pip freeze you can capture all dependencies of your programs including secondary dependencies and their exact version numbers.
So it's really important to capture the secondary dependencies also because if you only specify the first level or top level dependencies, what could happen is there might be a silent update for a secondary dependency and this could then cause trouble down the line when someone tries to install your program at a later point in time.
To avoid surprises, it's a good idea to always provide a requirements file that includes all of the secondary dependencies and their exact version numbers with your program.

Now that you know how to capture dependencies using the pip freeze command, let's talk about how you can take a requirements file and restore the dependencies of a program.
Early on I said that requirements files are really just a bunch of pip install commands inside a text file, and this is going to explain how we can take a requirements file and use it to reinstall all of the dependencies that are listed in it.
To do that, you need to call the pip install command and use it with the -r command line flag and then pass the name of the requirements file to it.
Let's take a look at how that works in practice.
So I am back in the previous directory that I used in the pip freeze example, but I've recreated the virtual environment from scratch so that it's now empty again.
Running the pip list command shows that that's the case.
But this directory still includes the requirements.txt file that I created the last time around, let's take a quick look at it.
So the requirements.txt file here lists all of the third party dependencies that I used in the previous example, now I am going to use the requirements.txt file to reinstall all of these dependencies in their exact same versions listed here.
The command you need for that is pip install -r and then you pass the name of the requirements file, I am going to go ahead and run this now.
As you can see here, this went over all of the requirements listed in the requirements.txt file and reinstall them in the exact same versions I used before.
So now when I do a pip list you can see that this recreated the environment I was using previously.
So this set of third party dependencies is an exact replica of the ones that I used in the previous example and I was able to restore them from the requirements file using the pip install command.
You just saw how you can restore Python dependencies, using a requirements file and the pip install command, let's do a quick review of the full workflow for capturing and restoring Python dependencies using requirements files.
Really what this comes down to is a three step process.
The first step, happens during ongoing development where you install necessary dependencies as you're working on your program.
For example, you might decide to install the Requests package because you need to support HTTP downloads in your program.
So you would just go ahead and do a pip install requests to install that package.
And when you're ready to deploy your program or even if you just need to take a snapshot to send to git or another version control system in order to share it with other developers, then you move on to step 2 and you capture the dependencies inside a requirements file.
For that you would use the pip freeze command and take its output and store it inside a requirements.txt file.
Now every time you want to deploy your program to another machine or want to set up another development environment on a different developers machine, that is when step 3 comes into place, this is where we restore the dependencies from the requirements file you created earlier, for that, you would run the pip install command with the -r requirements.txt flag.
This installs or updates all of the dependencies that were stored in the requirement's file in step 2.
Because the output of the pip freeze command also includes specific version numbers for those packages, this will recreate the exact same set of dependencies including secondary dependencies.

Let's discuss separating development and production dependencies for your programs.
A common challenge with Python dependency management in the real world is that your development and continuous integration environments need additional dependencies that the production environment doesn't need.
For example, your development environment might need additional testing frameworks, debuggers or profiling tools that are not really necessary in production, and might actually slow things down.
The same would be true for you continuous integration environment.
If you're running any kind of automated tests, you probably want to include testing frameworks and all kinds of other supporting tools for that on your built server environment.
But again, with all of this, the goal is for the production environment to still run lean and mean; now the good news is that there is actually a requirements files workflow that is well known and often used in the Python community that solves this problem.
The solution here is to create two different requirements files, one for development dependencies, and one for production dependencies, typically, these would be called requirements-dev.txt for the development dependencies, and requirements.txt for the production dependencies.
There is a feature in pip that allows you to link up requirements files so you can make this workflow very convenient for developers.
They only need to remember to install the requirements-dev file and that will automatically pull in and install all of the production dependencies as well, let's take a look at a real world example for this technique.
So I am looking at Love here which is a Python web application that was created by the fine folks at Yelp, and you are going to see in a minute now that they are using the exact same pattern for managing their development in production dependencies.
So right now, I am in the root folder of this repository here and when I scroll down, I'll find those two requirements files, so there is a requirements.txt and then there is also a requirements-dev.txt.
And this is exactly the split that I talked about earlier, so when you look at requirements.txt you can see that this includes all of the production dependencies in their exact versions, and nicely enough, they actually put a little comment here to explain what is going on, I think this is a really great use of the commenting feature that you can use in requirements files by the way.
So, these are just the production dependencies that would be necessary to run the application in a production environment, now let's look at the other requirements files.
So there is also this requirements-dev.txt and what this does, it first of all pulls in the production requirements and then it installs a bunch of additional development dependencies, so it pulls in a testing framework and the mark module, and some other modules that are useful during development but not really on a production machine.
And what's interesting here is that for some of the dependencies they actually pin them to specific version, so every time you specify an exact version that is called pinning, and this is our version pinning and this is exactly what they do here.
But then for this other dependency called ipdb which is an enhanced version of the Python debugger, they do not pin the dependency and this makes a lot of sense because the ipdb debugger would never actually run on an automated test server, but it's more something that a developer would run on their local machine.
So it might make sense to leave that dependency unpinned so it will always upgrade to the latest version.
Now, again you can see here that they put this little header explaining what is going on in this file, and I think this is really helpful.
Now these two requirements files cover the two usecases we discussed earlier.
So if a developer wants to set this up on a new machine, they would clone the repository and then run pip install -r requirements-dev.txt and this brings in all of the development dependencies, but every time the application gets deployed onto a production system, all that happens is a pip install -r requirements.txt so that only the production dependencies are brought in.
If you're building a web application this workflow is specifically supported by platforms like Heroku, so what Heroku does when you deploy a web application to it, is it will look for a requirements.txt file in the root of your source repository and try to install those dependencies, so if you follow the requirements.txt and requirements-dev.txt split, it will only install the production dependencies and not the testing dependencies which is exactly what you want.
I like this workflow because it is simple but also highly flexible.

Now that you have a good idea about how requirements files work, and how you can leverage them to organize your Python dependencies, p let's talk about some best practices for structuring and organizing your requirements files.
When it comes to version specifiers, it's a good idea to use exact versioning most of the time, this is also called pinning 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.
It's also important that you include secondary dependencies in their exact version numbers.
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 on the next deploy and that might break your application.
So my recommendation here would be to use exact versions for all of your packages including secondary dependencies.
Now it may make sense to go without a version specifier for some development dependencies, for example, if you're using a third party debugger, like ipdb or pdbpp it can make sense to leave that unpinned so that you can always work with the latest version.
Personally, I am leaning towards pinning as many packages as possible.
From personal experience, I know that this can help avoid a lot of trouble.
When it comes to naming your requirements files the most popular choice seems to be requirements.txt and then also requirements-dev.txt file for those development dependencies.
Other popular choices for requirements files names, include requirements.pip or requirements.lock but really, this is just a naming convention and those files would function exactly the same as the requirements.txt files you've seen before.
Whatever you name your file, typically they would be placed in the root folder of your project, some projects also create a separate requirements folder, but services like Heroku typically expect that the requirements file 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 because you won't have to overwrite config variables and point them to a non standard location for your requirements files.
That is why I would recommend that you always put them into the root folder of your project.
One more handy feature in requirements files is that they support comments, you can see this in the example here, all you need to do is place a hash character, 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, for example, you could use them to explain the difference between your requirements.txt file and the requirements-dev.txt file, this will be helpful for any developer working with the project in the future.
Or you could leave a comment on a specific dependency to explain your choice or to explain why a specific version is needed, adding comments to your requirements files is a great idea.
There is a common question around ordering dependencies inside requirements files, so should you order them, what order should you put them in, usually I start my requirements files with the direct dependencies, so these would be the dependencies that I initially installed using the pip install command, this would include packages like requests, or Flask, and I like to sort them alphabetically because that makes it easier to find what I am looking for.
Then, after those direct dependencies I would put a section with secondary dependencies and I usually use comments to indicate the difference between the two.
So all of these secondary dependencies are dependencies that I didn't install directly through pip install but they were installed because a direct dependency required them.
For example here, if you pip install Flask it will bring in the Jinja2 templating library and also the Werkzeug library.
So my typical workflow here would be to capture all dependencies using the pip freeze command and then go through them in an editor to split them into direct dependencies and secondary dependencies and perform the ordering.
When you do a pip install using that requirements file 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.
Another best practice that you already learned about is the development and production environment split.
Pip allows you to link up requirements files so that when you install one, pip will go out and actually also install the other, 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.
Let's do a quick recap here, those were the requirements files best practices that you just learned, first, you learned about the importance of version pinning, second, we discussed naming schemes for requirements files, after that, you learned how to use comments in requirements files and then you learned how you can make your requirements files easier to understand by splitting the dependencies into first order and secondary dependencies.
And finally, we did a quick recap on the technique that allows you to split up your development and production dependencies.
If you follow these conventions, and best practices, it will make it easier for other developers to work with your Python projects.

Congratulations on completing the setting up reproducible environments and application deploys module in the course.
Here is what you learned.
You started out by learning what requirements files are, what they are good for and how they can help you out in your Python development workflow.
Next, you learned how to capture project dependencies using the pip freeze command; right after that, you learned how to restore captured dependencies using the pip install command.
In the fourth lecture, you learned how to separate your development and production dependencies, so that your production deploys can run lean and mean.
And last, you learned some best practices around requirements files that make working with them a little bit easier.
Here is a quick recap of this module in the course.
Requirements files allow you to specify all of the third party dependencies of a Python program.
This is really powerful, it allows you to make your dependency installs and application deployments fully repeatable.
The pip package manager includes everything you need to capture an restore third party dependencies.

Congratulations, you've made it all the way to the end of the course.
There was a lot to cover when it comes to Python dependency management.
Let's do a quick lightning review of what you learned in the course.
You now know how to manage project dependencies with the pip package manager.
You know how to isolate project dependencies with virtual environments to avoid version conflicts.
You know how to find and identify quality third party Python packages that you can use in your own projects.
And you also know how to set up repeatable development environments and application deployments.
All of those are important skills for any professional Python developer.
Programming Python is such a wide field and there is tons more to learn.
So if you are interested in getting more Python learning resources, check out my website at dbader.org There you can find many more videos and tutorials that will help you on your journey toward mastering Python.
Thanks so much for going through the course, I hope you had a great experience and learned a lot about Python dependency management.