Join us and get access to thousands of tutorials and a community of expert Pythonistas.
This lesson is for members only. Join us and get access to thousands of tutorials and a community of expert Pythonistas.
Production vs Development Dependencies
It’s often the case that you’ll want specific packages installed in your development environment that you don’t want installed in your production environment.
Unit testing frameworks like pytest would be a good example of this. They need to be installed for development of the application, but they aren’t needed for the application to function in the production environment. pyvim, the text editor used in this course, is another example of a development-specific dependency.
Create a new text file called requirements_dev.txt with pyvim:
$ pyvim requirements_dev.txt
A requirements_dev file like this would include all the dependencies from the requirements.txt file, plus pytest for testing:
-r requirements.txt
pytest>=4.2.0
It’s also helpful to have a requirements file with locked down, known-good versions of dependencies for use in a production environment. This way, no pip command can ever upgrade them and risk breaking the application.
You can create a copy of requirements.txt with this Shell command:
$ cp requirements.txt requirements_locked.txt
To lock down dependencies, change all occurrences of >= in requirements_locked.txt to ==.
00:00
Not every package you install during the development of your application is going to be an application dependency. For example, modules used for unit testing, such pytest, don’t need to be in a production environment because they’re only used during development.
00:19 What we’ll do is create a separate requirements file that incorporates all of the production packages, plus some extras that are used only for development.
00:30
The easiest way to do this is by creating a new requirements file called requirements_dev.txt.
00:41
To include all of the requirements from the production version, use -r requirements.txt. Now we can add any more requirements specific for the development environment.
00:55 You can think of this as copying and pasting the regular requirements file into this special development requirements file. This works because all production packages need to be in the development environment, but no development-specific packages need to be in the production environment.
01:16
One last thing you might want to do is freeze your requirements for production. It’s great being able to have pip upgrade your packages automatically, and it’s okay if that breaks something in a development environment, but you don’t want that happening in a production environment.
01:33
The solution to this is to create a copy of the production requirements file and lock them down to specific versions that you know worked in a development environment. This way, pip can never upgrade them and break the production environment. To do this I’ll exit VIM with :wq and now I’ll use the Unix cp program to create a duplicate copy of requirements.txt called requirements_locked.txt.
02:11
I’ll edit that file and I’ll just go through one by one and replace the >= with a ==.
02:26
I’ll run a Unix command that will list any files in the directory starting with req and as you can see, we’ve got our three requirements files. requirements sets the base for our development requirements, requirements_dev is used in the development environment to add on development-specific packages, and requirements_locked is a special version of requirements with locked-down known good dependencies. Use requirements_dev in the development environment and requirements_locked in a production environment. Next, let’s see how to uninstall packages.
Become a Member to join the conversation.