How to Create a virtualenv with a Specific Python Version

By the end of this page, you will understand how Python virtual environments choose an interpreter, how to create an environment with a specific Python version, and how developers use this in real projects to keep dependencies isolated and reproducible.

A Python virtual environment is an isolated workspace that contains its own Python executable and installed packages. This lets one project use one set of dependencies while another project uses a different set.

The key idea behind your question is that a virtual environment is created from a specific Python interpreter. If you have Python 3.10, 3.11, and 3.12 installed, the environment will be based on whichever interpreter you tell the tool to use.

This matters because:

• Some projects only support certain Python versions.
• Packages can behave differently across Python versions.
• Teams often need consistent development environments.
• Deployment targets may require matching the production Python version.

In practice, when you create a virtual environment, you usually do one of these:

• Run a specific Python executable with -m venv
• Tell virtualenv which interpreter to use with -p

The environment does not magically switch Python versions later. Its version is decided when the environment is created.

Think of Python versions as different models of the same machine, and a virtual environment as a private workshop built around one machine.

If you build the workshop around Python 3.11, that workshop uses Python 3.11. If you want Python 3.12 instead, you build a new workshop around Python 3.12.

So the important question is not "How do I change the workshop afterward?" but "Which machine do I use when I build it?"

The most common modern approach is to use the interpreter directly:

python3.11 -m venv myenv

This creates a virtual environment named myenv using Python 3.11.

If you are using virtualenv, you can specify the interpreter with -p:

virtualenv -p python3.11 myenv

You can also provide the full path to the interpreter:

virtualenv -p /usr/bin/python3.11 myenv

Example using venv

python3.10 -m venv env310
source env310/bin/activate
python --version

On Windows:

py -3.10 -m venv env310
env310\Scripts\activate
python --version

Explanation:

• python3.10 -m venv env310 creates the environment with Python 3.10.
• Activating it updates your shell so python points to the environment's interpreter.
• python --version confirms which version the environment is using.

Consider this example:

python3.11 -m venv demoenv
source demoenv/bin/activate
python --version
pip install requests

Step by step:

1. python3.11 -m venv demoenv

   • Your system finds the python3.11 executable.
   • That interpreter creates a new virtual environment folder named demoenv.
   • Inside it, Python binaries and package-management tools are set up.

2. source demoenv/bin/activate

   • Your shell is updated so commands like python and pip point to the environment.
   • You are still on the same machine, but now using the environment's private Python tools.

3. python --version

   • This should print Python 3.11.x.
   • That confirms the environment was created from the intended interpreter.

4. pip install requests

   • The package is installed only inside demoenv.
   • It does not affect global packages or other virtual environments.

A useful check is:

Here are common situations where choosing the Python version matters:

• Maintaining older applications

  • A legacy app may require Python 3.8 even if your system default is 3.12.

• Testing compatibility

  • A library maintainer may create one environment for Python 3.9 and another for 3.11.

• Matching production

  • If a server runs Python 3.10, developers often create local environments with Python 3.10 too.

• Learning and experimentation

  • You may want to compare how code behaves between Python versions.

• Dependency isolation

  • Some packages work only on certain versions, so separate environments avoid conflicts.

In real projects, developers usually combine version-specific environments with a few standard habits:

• Pinning the Python version

  • Projects often document a required version in a README, pyproject.toml, .python-version, or CI configuration.

• Creating fresh environments per project

  • Instead of reusing one environment for many apps, each project gets its own environment.

• Using guard checks

  • Scripts may verify the Python version before running:

import sys

if sys.version_info < (3, 10):
    raise RuntimeError("Python 3.10 or newer is required")

• Testing across versions

  • Teams often run automated tests against multiple Python versions in CI.

• Avoiding global installs

  • Dependencies are installed into the active environment, not system-wide.

• Recreating instead of mutating

  • If the wrong Python version was used, developers usually delete the environment and recreate it with the correct interpreter.

1. Assuming activation changes the Python version

Activation does not choose the Python version. It only starts using the environment that was already created.

Broken assumption:

python3.12 -m venv env
source env/bin/activate
# expecting it to become Python 3.10 somehow

Fix: create the environment with the correct interpreter from the start.

2. Using python -m venv when python points to the wrong version

python -m venv myenv

This uses whatever python currently means on your system, which may not be the version you want.

Fix:

python3.11 -m venv myenv

3. Forgetting to verify the version

After activation, beginners often install packages without checking the interpreter.

Fix:

python --version

4. Trying to change the Python version inside an existing environment

A virtual environment is tied to the interpreter it was built from.

Fix:

# Create with built-in venv
python3.11 -m venv myenv

# Activate on macOS/Linux
source myenv/bin/activate

# Activate on Windows CMD
myenv\Scripts\activate.bat

# Activate on Windows PowerShell
myenv\Scripts\Activate.ps1

# Check version
python --version

# Using virtualenv instead
virtualenv -p python3.11 myenv

# Using full path
virtualenv -p /path/to/python3.11 myenv

# Windows launcher
py -3.11 -m venv myenv

Key rules:

• The Python version is chosen when the environment is created.
• Activation does not change the environment's Python version.
• If you used the wrong version, recreate the environment.
• Prefer explicit interpreter names when multiple versions are installed.
• Verify with python --version after activation.

How do I create a virtual environment with Python 3.11?

Use an explicit interpreter command such as:

python3.11 -m venv myenv

Or on Windows:

py -3.11 -m venv myenv

Can I change the Python version of an existing virtual environment?

No. A virtual environment is tied to the interpreter used to create it. Create a new environment with the correct version instead.

Should I use venv or virtualenv?

For most modern Python projects, venv is enough and is built in. Use virtualenv if your workflow specifically requires it.

Why does my environment use the wrong Python version?

You probably created it with python -m venv when python pointed to a different interpreter than expected.

How can I see which Python versions are installed?

That depends on your system. Common checks include python --version, python3 --version, python3.11 --version, or on Windows py -0.

• Python virtual environments — The broader concept of isolated Python project environments.
• Python interpreter — A virtual environment is created from a specific interpreter.
• PATH environment variable — Determines which python command your shell finds.
• pip — Installs packages into the active virtual environment.
• venv module — The built-in Python way to create virtual environments.
• virtualenv package — A third-party tool for creating virtual environments.
• Dependency management — Virtual environments help keep project dependencies separate.
• Python version compatibility — Many libraries and projects depend on specific Python versions.