Exploring More Pipenv Features

00:00 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.

00:31 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.

00:52 The 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.

01:05 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.

01:31 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.

01:42 The .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.

02:05 konnichiwa! With the new shell active, you can run the pipenv check command to verify the packages installed.

02:15 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.

02:43 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.

02:55 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 dev and production libraries using pipenv.

03:09 Let’s see how that’s done.

03:16 Adding the --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…

03:30 And you can see colorama is in the dev-packages section. Let’s install requests to see the difference.

03:44 And 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.

03:56 If you want to clean up your virtual environment by removing the dev-specific stuff, you can pass the --all dev flag to the uninstall command.

04:10 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.

04:25 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.

04:39 --venv shows where your virtual environment lives.

04:46 And --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.

05:04 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.

05:21 If you’re converting a project and already have a requirements.txt file, pipenv will automatically read it and build you a pipenv file when you first use the shell subcommand.

05:32 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.

05:56 Passing the --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.

06:11 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.

06:28 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.

06:39 You still use the install_requires keyword in your setup.py or 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.

06:55 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.

07:22 That’s pipenv in a nutshell. Last up, I’ll summarize the course.