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.
.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.
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.
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
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.
--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.
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.
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.
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.
Become a Member to join the conversation.