Exploring More Pipenv Features
In the previous lesson, I showed you how to use
pipenv to install packages in a virtual environment. In this lesson, I’ll show you a few more
pipenv subcommands. A couple of lessons ago, I mentioned that you might want to muck around inside the
site-packages directory. Well,
pipenv provides the
open subcommand to give you a shortcut for doing the same thing in your virtual environment. When you run
pipenv open, your editor will be spawned, editing the installed package. Of course, what that means will vary depending on your editor.
I’m old school and use
vim. For me, I get a directory listing of the files in the package, which I can then click on to edit. Your experience will depend on your editor of choice. If you’re running in a Unix-derivative operating system, like Mac or Linux, you can specify what editor gets run by an environment variable.
graph subcommand shows you a list of the packages installed and all their dependencies. This is kind of like a
pip freeze, except it also provides version range information. This command can be helpful if you’re running into version conflicts.
You can run the
pip install command with a
--skip-lock argument to do the install but not create a lock file. You could then use this
graph subcommand to see what it did, and hopefully figure out how to resolve your conflicts.
01:20 Oftentimes your project will have specific environment variables. This is becoming increasingly common, especially with cloud computing, where configuration is frequently passed in this way.
pipenv will automatically read a
.env file in the root folder of your project and import it into your environment. This is a handy shortcut that saves you doing it manually yourself.
.env file format is a list of key/value pairs and looks the same as how you specify environment variables in most terminal shells. I’ll demonstrate the next couple in a terminal. Lets go build another project.
konnichiwa! With the new shell active, you can run the
pipenv check command to verify the packages installed.
PEP 508 has to do with dependency specifications, and the
check command makes sure that everything is as it should be. All right, let me leave the shell. Outside of the shell, you can use the
pipenv run command to run something as if you were inside the shell. Let’s run
pipenv check again, but this time without actually being in the shell.
pipenv run allowed me to run
pipenv check as if I was inside the shell, even though I wasn’t. Speaking of the shell, let me go back inside.
Note that because the virtual environment already exists for this project, nothing new gets created this time. The
shell command just activates the environment. Previously, I’ve hinted at the ability to have
production libraries using
03:09 Let’s see how that’s done.
--dev flag to the
install command installs the resource but puts it in the
dev-packages section of the Pipfile.
03:24 Just going to cat the Pipfile to the screen here quickly…
And you can see
colorama is in the
dev-packages section. Let’s install
requests to see the difference.
colorama is in the dev section, while
requests is in the default. With the use of a command-line flag, you can specify two different environments without having to maintain two different specification files.
If you want to clean up your virtual environment by removing the dev-specific stuff, you can pass the
--all dev flag to the
colorama got removed. Or if you make a mistake and want to start from scratch, you can just use the
--all flag to remove everything.
That’s much handier than having to specify every single item by name like I did when using
pip. There are also a couple of flags you can call with
pipenv in order to get some information.
--venv shows where your virtual environment lives.
--where tells you where the root of your project is. In this case, it’s pretty obvious, but if you’ve got a complicated project and you’re many levels deep, or you need that information in a script, this can tell you where things are based. Okay, you’ve got your environments handled. You’ve written some code.
Now you want to share it. How do you use
pipenv to distribute things? If you aren’t using a Python package, but just giving someone your code or letting them check it out of your version control directly, then you replace
requirements.txt with a Pipfile.
If you’re converting a project and already have a
pipenv will automatically read it and build you a
pipenv file when you first use the
You want to be a little careful with this, as
pipenv will fully pin everything based on the contents of your
requirements.txt file, and it puts it in the Pipfile itself, not the lock file.
05:43 So you may want to edit the Pipfile after you’ve done this. Regardless of how you got there, the lock file contains the full specification of your virtual environment, and it’s the file you want to use to install everything.
--ignore-pipfile flag to the
install subcommand will use the lock file explicitly. This is the typical way of getting your pinned environment built out in a new place.
install also supports a
--dev flag. This is what you use in order to build out an environment, including your development packages. Using
install, with or without these two flags, gives you all sorts of control over your environment.
So that’s without a package. What if you are trying to build a package and formerly using
requirements.txt? Well, if you want to switch, there’s a few things to keep in mind.
You still use the
install_requires keyword in your
setup.cfg file, and this value should contain the minimum base dependencies of your package, just like it did before. You should include the Pipfile with your distro and keep it in your version control.
The Pipfile should specify the same libraries as your
setup.py file. With all that in place, you can install the dependencies using
pipenv install and the
-e argument with a dot to grab the local installation set up.
07:11 This will generate your lock file, which you should then also include in your distro and version control so anyone grabbing your source can create the same environment in their environment.
pipenv in a nutshell. Last up, I’ll summarize the course.
Become a Member to join the conversation.