Photo by Pakata Goh on Unsplash

So you're sitting there, you've just run python -m venv venv, everything looks fine, and then you type source venv/bin/activate and... nothing. Or worse, you get a red error that makes zero sense. I've been there more times than I'd like to admit, and I've watched juniors lose 45 minutes to this exact thing when they could've been shipping actual code.

Python virtual environment setup is one of those things that should be a one-liner but has a weirdly high failure rate depending on your OS, your Python version, and sometimes honestly just the mood of your machine. Let's talk about what actually goes wrong and how to fix it fast.

What the Error Usually Looks Like

The most common error on Windows looks like this:

venv\Scripts\activate : File C:\Users\yourname\project\venv\Scripts\Activate.ps1 
cannot be loaded because running scripts is disabled on this system.
CategoryInfo          : SecurityError: (:) [], PSSecurityException
FullyQualifiedErrorId : UnauthorizedAccess

On Linux or Mac, you might see something like:

bash: venv/bin/activate: No such file or directory

Or this gem that shows up when your Python install is broken or incomplete:

Error: Command '['/home/user/project/venv/bin/python', '-Im', 'ensurepip', '--upgrade', 
'--default-pip']' returned non-zero exit status 1.

Each of these has a different root cause, so let's go through them one by one.

Fix #1 — The Windows PowerShell Script Block (Most Common)

If you're on Windows and you see that "running scripts is disabled" message, it's not a Python problem at all — it's PowerShell's execution policy refusing to run unsigned scripts. Which, fine, security and all that, but it's annoying when you're just trying to work.

Run this in PowerShell as Administrator:

Set-ExecutionPolicy -ExecutionPolicy RemoteSigned -Scope CurrentUser

Then try activating again:

venv\Scripts\activate

If you're using Command Prompt instead of PowerShell (and honestly CMD is underrated for this kind of thing), use this instead:

venv\Scripts\activate.bat

That bat file bypasses the whole PowerShell policy thing entirely. I've seen people spend an hour on the policy fix when they could've just switched to CMD.

Fix #2 — The "No Such File or Directory" on Linux/Mac

This one usually means one of two things: the venv didn't actually create properly, or you're running the activate command from the wrong directory. I've done that second one more than I care to admit — you're in /home/user trying to activate a venv that's in /home/user/myproject.

First, double-check you're in the right folder:

ls -la

You should see a venv/ directory right there. If you don't, you're in the wrong place or the venv creation failed silently.

Now here's where it gets tricky — on Ubuntu and some Debian-based systems, the venv module isn't included with Python by default. Yeah, I know. You'd think it would be, but it's not. You'll need to install it separately:

sudo apt install python3-venv

Then recreate your virtual environment:

python3 -m venv venv
source venv/bin/activate

Notice I'm using python3 explicitly. On a lot of Linux systems, just typing python still points to Python 2.x, which is a whole other headache. Always use python3 on Linux unless you've specifically aliased it otherwise.

Fix #3 — The ensurepip Error (Broken Python Install)

That ensurepip error is usually a sign your Python installation is incomplete or corrupted — it's missing the pip bootstrapping component. This is really common when you've installed Python from a package manager that strips out optional components (looking at you, certain minimal Docker base images and some Linux distros).

On Ubuntu/Debian:

sudo apt install python3-pip python3-venv
python3 -m venv venv --without-pip

Then manually install pip into the environment:

source venv/bin/activate
curl https://bootstrap.pypa.io/get-pip.py -o get-pip.py
python get-pip.py

Alternatively, if you're using pyenv to manage Python versions (which, in my experience, is the single best thing you can do for your sanity on a dev machine), reinstalling the Python version through pyenv usually fixes it cleanly:

pyenv install 3.11.9
pyenv local 3.11.9
python -m venv venv

Pyenv compiles Python with all the expected components included, so you don't run into the stripped-down install problem.

Quick Check: Is the Environment Actually Active?

After activating, you should see (venv) at the start of your terminal prompt. If you don't see it, the activation didn't work even if no error appeared. You can also verify it programmatically:

python -c "import sys; print(sys.prefix)"

If the output shows your venv path (something like /home/user/myproject/venv), you're good. If it shows your global Python path, something's still off.

Fallback: Just Use virtualenv Instead

If venv is still giving you grief and you need to move on with your life, just use virtualenv — it's the older, more battle-tested tool that venv was based on anyway. It tends to handle edge cases better and has more explicit error messages.

pip install virtualenv
virtualenv venv
source venv/bin/activate  # Mac/Linux
venv\Scripts\activate     # Windows

Honestly, for complex projects or when I'm setting up CI environments, I still reach for virtualenv out of habit. It just works.

One last thing — if you're using VS Code and the terminal inside it isn't picking up your virtual environment even after activation, check your Python interpreter setting. Hit Ctrl+Shift+P, type "Python: Select Interpreter", and point it at the Python binary inside your venv folder. VS Code sometimes latches onto the global interpreter and ignores the active venv, which causes its own set of confusing import errors that have nothing to do with your actual code.

Hope this saves you the 40-minute rabbit hole. The virtual environment stuff really should be smoother than it is, but at least now you know where the bodies are buried.

Related: Python externally-managed-environment Error: Fix It Without Breaking Your System