Virtual environment naming options
In this part we have so far called our virtual environments for both projects ( demo-app and demo-app-2 ) env . To begin with, this might seem a little confusing. This is my personal preference and a convention that is used fairly widely in industries. You can, of course, name your virtual environments however you wish.
Why don’t we give all our virtual environments a unique name?
You want to change environments quickly
If you are changing between lots of different projects very quickly, it is more convenient to activate your virtual environment using source env/bin/activate . This is instead of using ls to list files/directories in the root of your project to identify (or remind yourself of) the virtual environment name and then running source <env name>/bin/activate to activate your virtual environment.
To keep the .gitignore file simple
The virtual environment directory is generally not included in the git repository for a project. Instead, the directory is added to the .gitignore file. For example, let’s set up demo-app as a Git repository by running git init .
~/projects/demo-app → git init Initialized empty Git repository in /Users/george/projects/demo-app/.git/ ~/projects/demo-app →
If you now run git status you will see that demo.py is an untracked file and that the virtual environment (the env directory) is also untracked:
~/projects/demo-app → git status On branch master No commits yet Untracked files: (use"git add <file>..." to include in what will be committed) demo.py env/ nothing added to commit but untracked files present (use "git add" to track) ~/projects/demo-app →
You don’t want to commit the virtual environment directory, so we will add that to a .gitignore file instead. Create a file called .gitignore with the following contents:
env/
Now, if you run git status you should only see the demo.py file and the newly created .gitignore untracked - we have successfully ignored the env directory:
~/projects/demo-app → git status On branch master No commits yet Untracked files: (use "git add <file>..." to include in what will be committed) .gitignore demo.py nothing added to commit but untracked files present (use "git add" to track) ~/projects/demo-app →
Now you can add both the files and create an initial commit:
~/projects/demo-app → git add .gitignore ~/projects/demo-app → git add demo.py ~/projects/demo-app → git status On branch master No commits yet Changes to be committed: (use "git rm --cached <file>..." to unstage) new file: .gitignore new file: demo.py ~/projects/demo-app → git commit -m "initial commit" [master (root-commit) e989330] initial commit 2 files changed, 6 insertions(+) create mode 100644 .gitignore create mode 100644 demo.py ~/projects/demo-app (master) →
Now, let’s imagine a scenario where you have 10-15 developers working on an individual project. If they each give their virtual environment a unique name and add it to the .gitignore , it will quickly become very messy and unmanageable!
Why don’t we call our virtual environment the same name as the project it is associated with?
This one has a simple answer: this makes the directory names clash, which often causes confusion.
For example, if, in demo-app , we create a virtual environment called demo-app , our directory structure would look like this:
~/projects/demo-app (master) → ls demo-app demo.py ~/projects/demo-app (master) →
Exercise
Create 3 different projects, each containing a script. Each script should contain the same script. The script should use the
requestslibrary to make a get request tohttps://www.example.com.Create a virtual environment in each project directory, but make sure you give each virtual environment a different name.
If you are comfortable working with
git, initialize each repository as a git repository and add each virtual environment to the.gitignorefile.Practice switching between the virtual environments at speed and running each project.
Repeat the above tasks, but this time name all of your virtual environments
env.Decide which naming conventions you find easier!
Check Your Work
Watch me go through the exercise:
Let’s Recap!
Understand the pros and cons of naming virtual environments in particular ways.
Establish a preference for how you name your virtual environments.
Now that you have learned best practices for naming virtual environments, let’s consider how to specify which packages are in a virtual environment using a requirements file.
