Introduction

Environment variables are not owned by virtualenv, but virtual environments are a convenient place to set them for a project. The main choices are: export them manually after activation, add them to the activation script, or use a dedicated configuration tool so secrets and per-project settings stay out of the codebase.

Set It for the Current Shell

If you only need the variable for the current activated shell:

source venv/bin/activate
export APP_MODE=development
export API_TOKEN=example-token

This is the simplest answer, but it only lasts for that shell session.

That is often a good thing for temporary testing, because it leaves the virtual environment untouched and avoids hiding configuration inside generated files.

Set It Automatically on Activation

If you want the variable whenever the virtual environment is activated, add it to the environment's activate script:

# inside venv/bin/activate
export APP_MODE=development
export API_TOKEN=example-token

Then activate normally:

source venv/bin/activate

That works, but it means the environment directory now contains local configuration details that may differ between developers or machines.

It also means the customization disappears if you delete and recreate the virtual environment, which is common during dependency cleanup.

Unset on Deactivation

If you add variables on activation, it is good practice to remove them on deactivation too. A simple pattern is:

export APP_MODE=development

and later inside the deactivate logic:

unset APP_MODE

That keeps the shell cleaner after leaving the environment.

On Windows, the same idea applies, but the activation logic lives in the platform-specific scripts for cmd.exe or PowerShell rather than venv/bin/activate.

Better Project Workflow

For team projects, editing venv/bin/activate is often a little too local and a little too hidden. Many teams prefer:

• '.env files'
• 'python-dotenv'
• shell wrapper scripts
• container or deployment configuration

That makes environment management more explicit and easier to document.

For example with python-dotenv:

from dotenv import load_dotenv
load_dotenv()

Then variables can live in a .env file rather than being hardcoded into the virtual environment scripts.

A simple .env file might look like this:

APP_MODE=development
API_TOKEN=example-token

That keeps configuration near the application and makes it easier to document expected settings for other developers.

Wrapper Scripts Versus Application Loading

There are two clean patterns here. One is to export variables in a shell wrapper before starting the program. The other is to let the Python application load them from a .env file at startup.

The wrapper style is useful when subprocesses also need the variables. The application-loading style is useful when you want local development setup to stay close to the code and easy to reproduce.

Why This Matters

Virtual environments isolate Python packages, but they do not automatically isolate shell configuration. That is why people often expect virtualenv to have a built-in "set env vars" feature and then discover they still need shell-level or application-level configuration.

Understanding that separation makes the tooling choices much clearer.

Common Pitfalls

• Assuming virtualenv automatically persists shell environment variables.
• Editing venv/bin/activate and forgetting that recreating the environment may wipe the change.
• Storing secrets in tracked files by accident.
• Committing a real .env file instead of a safe .env.example template.
• Forgetting to unset variables when they should be temporary.
• Mixing package isolation and configuration management as if they were the same problem.

Summary

• You can export variables manually after activation for quick local use.
• You can add exports to venv/bin/activate for automatic activation-time setup.
• For team-friendly workflows, .env files or dedicated config tools are often better.
• 'virtualenv isolates packages, not all shell state.'
• Choose the approach based on whether the variable is temporary, local, or shared.