Just to give credit where credit was due, that was @pradyunsg 's advice to me above, I just
stole shared it with you
Really, the parts you actually need to know as a user are pretty straightforward. You can think of a Python venv as an isolated set of Python packages, where packages you install/upgrade/remove inside the environment don’t affect anything outside it, and likewise those you install/upgrade/remove outside of it don’t affect anything inside it. I.e., anything you do with
pip in the environment, stays in the environment.
You can have as many as you want and can create them wherever you want; each of them lives in a specific directory that you can name whatever and put wherever you want, but for basic usage, you usually create it inside your top-level directory for a project (that contains your scripts, modules, data etc that you’re working on). So, to create a venv,
cd to that directory and run
python -m venv <env_name>
<env_name> with the name of the directory you want Python will create inside your project dir to contain the venv; they are often named
.venv, though you can also give the directory a more descriptive name for your project, so you can tell it apart from other environments when its activated (since that’s the name shown in the command prompt).
You only need to create it once, but whenever you open a new command prompt and are ready to start working in that environment (running
python, installing packages with
pip, etc), you need to activate it. On Windows, you do so by running, while in your project directory,
You can confirm its activated by entering
where python, and you’ll see the path to the Python inside the
<env_name> directory instead of the global install.
That’s it; now any time you run
pip, etc. in the same command prompt window, they will run inside the virtual environment. To deactivate the environment, simply type
Hey, I’m not a professional programmer either…I just play one on the internet.