Set Up a Python Environment

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.

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!

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  requests  library 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  .gitignore  file.

• 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.