This post is a personal study note created while learning the topic discussed. Some information may be inaccurate or incomplete. If you notice any errors or have suggestions, I’d sincerely appreciate your feedback.
Before diving into Django, you first need to set up something called a Python virtual environment. So let's start by understanding what a Python virtual environment is.
Python virtual environment
A Python virtual environment is a tool that creates an
isolated Python environment specifically for a single project.
It keeps the dependencies and packages for different projects
separate from each other
Why is a Virtual Environment Necessary?
A virtual environment is essential because it allows each project to maintain its own set of dependencies without interfering with others.
For instance, one project might require Django 3.x, while another might need Django 4.x. A virtual environment lets each project use the version it needs without conflict.
It also keeps your system Python clean, as packages are installed only within the project's environment rather than system-wide, reducing the risk of version clashes.
Additionally, virtual environments make collaboration easier: by listing all necessary packages in a file like requirements.txt, team members can quickly recreate the same development environment on their own machines.
requirements.txt
The requirements.txt file can be thought of as a grocery list for a recipe in everyday life.
Just like you would list ingredients like pasta, heavy cream, cheese, and garlic to make a creamy pasta dish, requirements.txt lists the packages needed to run a Python project properly.
With this list, anyone can prepare the same ingredients and recreate the dish, meaning the development environment, anywhere. Just like specifying exact amounts in a recipe ensures consistent taste, including precise package versions in the file helps maintain consistency across different setups.
Trying Python virtual environment
Now let’s open the Command Prompt in Windows and create a directory named C:/venvs by entering the appropriate command. While the root directory doesn’t necessarily have to be C:/venvs, we’ll use it here for convenience and consistency throughout this tutorial.
C:\Users\user>cd /
C:\>mkdir venvs
C:\>cd venvs
C:\venvs>
Bash
복사
And we are going to make virtual environment under that path
The command python -m venv uses a built-in Python module called venv to create a virtual environment. The word that comes after, such as mysite, is simply the name you’re giving to that virtual environment. You don’t have to name it mysite, you can choose any name you like, such as cutesite. If you decide to use a different name, just mentally replace all instances of mysite in this tutorial with your chosen name.
For macOS users, create a venvs directory under your home directory (e.g., /Users/your-username).
On macOS, do the same by navigating into the venvs directory and using the venv module to create a virtual environment named mysite.
We have created the mysite directory under the venvs directory, this will be the location where we build our project during the exercises. However, just creating the mysite folder under venvs doesn't mean the virtual environment has been activated. So, let's take a look at how to activate the virtual environment.
Windows
We’ve created the mysite directory under the venvs directory. Now, let’s navigate to the Scripts folder inside it using the command below.
cd C:\vevns\mysite\Scripts
Bash
복사
dir
Bash
복사
After navigating to the Scripts folder, running the dir command displays a list of directories and files contained within it. Directories are marked with <DIR>, while files typically have extensions like .bat, .ps1, or .exe.
Now, enter the activate command in this directory. If you see (mysite) appear as shown in the image below, it means you’ve successfully activated the virtual environment.
activate
Bash
복사
MacOS
On macOS, after creating the mystie virtual environment, you'll find a bin directory inside it, which serves the same purpose as the Scripts directory on Windows. However, instead of navigating into bin, you typically activate the environment using source mystie/bin/activate from the parent directory.
Now you need to run the activate script to activate a virtual environment. However, unlike Windows, you must use the source command, like source mystie/bin/activate so that the environment is applied to your current shell session properly.
The reason why you need to use the source command when activating a virtual environment on macOS is due to how the shell works. Shells like bash or zsh, commonly used on Linux and macOS, execute scripts in a new subprocess (a subshell) by default. When this happens, any environment variable changes or settings made by the script are only applied within that subprocess. Once it ends, those changes are lost and not reflected in your current terminal session.
To ensure that the environment changes take effect in the current shell, the source command is used. This command makes the shell run the script in the current session, so changes like modifying the PATH or setting other environment variables persist. For example, running source venv/bin/activate activates the virtual environment in the current shell, allowing you to use the virtual environment's Python interpreter and packages.
On the other hand, Windows works differently. In cmd.exe or PowerShell, simply typing activate is usually enough. This is because the activation scripts on Windows (activate.bat or Activate.ps1) are designed to run directly in the current shell context, so their effects are applied immediately without needing a special command like source.
After running the source activate command, if you see mysite appear in blue on the right side of your terminal, it means the virtual environment has been successfully activated. (Depending on your terminal settings, mysite might appear on the left side of the prompt instead.)