Installing Packages Using pip
In the previous lesson, I gave an overview of the course. In this lesson, I’ll show you Python’s built-in package installation tool,
pip. Python has a long history of package management, and there have been several different tools over the years.
00:14 This can be quite confusing sometimes, especially if you’re working on older code or packages. It is also an area that is in flux in the language. People are still trying to solve certain thorny package management problems.
The most up-to-date of the package management tools that ships with Python is called
pip. It is a command-line tool that installs third-party packages from the PyPI package repository. You can install packages from elsewhere as well, but that’s the default. When you install a package using
pip, the package goes in the
site-packages directory of your interpreter’s installation. This is problematic if you’re managing multiple projects that require different versions of the same package. Virtual environments are a solution to this problem, but for now, let me show you how
pip works without the virtual env.
For this demonstration, I’m using a clean installation of Python 3.10. I’ve done this so that you can see the base state of things before I start installing packages. The results of the
show_path script print out the various places Python will look for code.
The first item is my current directory. The rest of them are deep within the installation of the interpreter. I’m running this code on the Mac. The
/Library/Frameworks place is where Mac keeps all this stuff.
freeze subcommand lists all the current packages that are installed. Nothing was returned here because nothing yet has been installed. It’s a clean base system. All right, then, so let’s install a package.
03:45 The wheel format is one of several different ways of assembling a package. You can think of it kind of like a ZIP file containing the contents of the code to be installed. It goes much deeper than that as it also could contain code that can be compiled locally, metainformation, and different content depending on your version of Python.
These two folders contain the code and metainformation about the install, respectively. There really isn’t any magic here. The
colorama folder contains code, just like code you might write in your own directory. In fact, you can edit the files in
colorama, and it will affect what happens when you import the library. You want to be careful if you’re doing this, of course, as you’re making changes from the original, and they only will be local to your installation, but I dig around in the
site-packages directory all the time when I’m coding.
05:07 If you want to better understand what someone’s library is doing, you can look at the code directly. There are some caveats here. If the library uses C extensions, then the directory will contain compiled code, but if the library is Python based, you can see it in all its gory details.
You can also get fancy with your installation and ask for packages in a range. For example, you could say you want something greater than 0.3.3, but less 0.4.0. In that case, you’d get the largest dot-3 release, which for
colorama would be 0.3.9.
Notice a few things in the output here. For starters, because version 0.3.3 is older, it didn’t have a wheel package. Not a problem.
pip knows how to use the older formats as well and tells you so. Second,
colorama-0.4.4 was already previously installed. Because of this,
pip uninstalls it first, then replaces it with 0.3.3.
I’ve used the
-y switch to answer
yes to the
are you sure message that happens per package by default.
pip found 0.3.3 of
colorama and uninstalls it. I’m back to having a clean base with no packages.
colorama is a small library with no dependencies.
You can use these same formats when you’re calling
pip install if you want to restrict your package ranges the same way. The last line of output from
pip tells you everything that happened as a result of the
install requests command. In this case, five different packages got installed. Back to
pip freeze, and there are the five installed packages.
And it shouldn’t be a surprise by now that inside of the
site-packages directory, you can see all the newly installed stuff. In order to get back to a clean base, you have to specifically uninstall each of the packages.
This can be very handy if you’re creating and testing your own packages. Inside the sample code, you’ll find two folders,
bonjour, both of which are installable packages. To keep things clean, I’m going to create a directory
-e parameter with
pip install does an editable install. This is an install from the local file system. It is called editable because
site-packages gets a link rather than a copy of the package, meaning you can still edit the package in the original directory.
There are actually several different ways of doing this, and the ins and outs of building packages is rather complicated. The script takes a dictionary containing attributes about the package, one of which is called
install_requires. This attribute takes a list of the names of packages that
hello is dependent on. In this case, it is
colorama 0.3.9. Like with
pip install, you can specify a range of packages by using other comparison operators than the
double equals), like here. For the purposes of this course, it’s not important to understand the details of how the dependencies are specified inside of a package.
Well, that was problematic. Like
bonjour also depends on
colorama, but this time on a different version number.
pip discovers this and conveniently uninstalls the older version for you. When I say “conveniently,” I mean it in the sense of “conveniently, I pointed the gun at my foot.”
pip does its best to warn you about the potential of losing toes, but it is just a warning. Why is this a problem? Well, it all depends on the library.
The good folks who wrote
colorama have kept their code fairly backward-compatible. In all likelihood,
hello will still work with
colorama 0.4.4., even though it says it is dependent on
0.3.9, but there’s no guarantee in this case.
12:57 It might not work with something earlier. This is why virtual environments are considered the best practice. The more projects you have on your system, the more likely it is that you’re going to have a dependency conflict.
13:36 Given the potential problems with library dependencies, a common practice is to pin your versions. This means recording exactly those libraries your project needs and making sure that if you deploy somewhere else, you get the same thing.
Remember, this didn’t get rid of the dependencies, just the
requests library itself. So right now there are four packages instead of five. You can use the
-r argument to
pip install to install a list of packages from a
I’ll cover that more in the next lesson. You’ve seen how
pip works. You’re almost ready to move on to
pipenv, but first, like all good little children, you need to clean up your toys. Let’s uninstall everything so that I’m back to a clean base before the next lesson.
Become a Member to join the conversation.