Python Projects With Less Pain: Beginner's Guide to Virtual Environments

TLDR;

To create a virtual environment:

• Navigate to your project directory's root folder
• Create a virtual environment
  • python -m venv .venv
• Activate it
  • Mac: source .venv/bin/activate
  • PC: .venv\Scripts\activate
• Install packages
  • pip install -r requirements.txt
• Deactivate when done
  • deactivate

Dead in the Water

I don't know about you, but my computer still has Python 3.9.6 installed. And just like every October, an old version of Python is being deprecated. This year just happens to be, you guessed it, Python 3.9. Surprise, surprise, stuff is starting to break.

To Update or Not to Update, is that the Question?

Sure, I could update Python. As tempting as that sounds, it won't solve all my problems.

Have you ever tried running a tutorial only to get an endless string of vague and frustrating error messages? Most of those are caused by:

• Dependency conflicts (i.e. a pandas update breaks compatability)
• Version conflict (a mismatch between your system and the tutorial)

Anyone remember pandas version 1.3.5? There was a breaking change around that version which wasn't backwards compatible with a critical piece of code I'd written. I'm almost embarassed to admit how long it took me to figure it out. But when you have code that was written more than three years ago, this is pretty common.

That's just part of code updates and improvements, right?

I should periodically review and rewrite my code, you say?

Well, kind of.

The Real World: Cloud Edition

I mainly work in cloud environments and need to be familiar both with seting up and using environments that are consistent across different cloud resources as well as work within the constraints of a system that has been predefined.

Ever heard a software developer say "But it works on my computer"? This is the cloud, except for everyone.

AWS is a great example of this. Sagemaker Studio AI usually has kernals that are pretty up-to-date, but the pre-configured resources for running pipelines tend to be just ahead of (or sometimes just behind) deprecation. As of October 15, 2025 here is a common set of environments:

• Stable Python relase: Python 3.14
• ml.t3.medium Sagemaker kernal: Python 3.12.9
• Preconfigured pipeline resources: Python 3.9

The Price of Easy

Python is popular because it's easy, but also because there is a plethora of libraries that cover just about any use case or situation. The big libraries that most of us rely on (like pandas, numpy, scipy, and scikit-learn to name just a few) get updated regularly. And each update is only compatible with certain versions of Python, usually those available and active at the time the update was released.

What does this mean? It means that if I prototype in my local environment with a freshly updated version of Python (3.14) or even in a Sagemaker instance (Python 3.12), that same code is highly unlikely to run in my pipeline (Python 3.9).

Environments, Virtual Environments

Cloud environments are like Bond, everyone wants to do what they can do. And when it comes to data science, they're the defacto solution unless you're running tiny datasets and predicting manually and/or offline.

So just like Bond needs a license to kill, you need to use virtual environments.

Virtual environments make matching the pace of updates vs resources a breeze and gives you these benefits:

• Isolate Python and package versions per project/code base
• Make your code portable across systems and cloud platforms
• Avoid dependency purgatory

May The venv Be With You

It's easy to get started. I learned a handly workflow in the University of Washington's Certificate in Python Programming.

1. On the command line, navigate to the directory of the project you're working on. If we use the folder structure of my old blog's repo datascience_diaries it'd look something like this: cd datascience_diaries/devto_posts/00_resources
2. Create a virtual environment: python -m venv .venv
   • In your environment the first command might be python or might be python3 depending on how you have python set up on your system
   • -m indicates that we want to run a python module/library/package
   • venv is the module we want to run. This is what does all the heavy lifting for us and creates the environment
   • .venv is what we want to call the virtual environment. You can call it anything, even something like platapus or tree_beard. The standard is to call it .venv
     • I've started naming my .venv file something related to my project so it's easy to differentiate from other environments. For ease of reference, I'll call this file .venv throughout the rest of the post
     • To get VSCode to recognize your environment, you'll need to open it at the root level of your project where the virtual environment is stored
3. Activate the environment
   • On Mac: source .venv/bin/activate
   • On PC: .venv\Scripts\activate

That's it. In your command line at the front of the line you should see something like (.venv), which let's you know that it's active. To deactivate it just type deactivate.

If you type pip list, as of October 15, 2025, you should only see two entries: pip and setuptools.

Mass pipduction

I recommend using a requirements.txt file to specify any/all packages to want to use in the environment so that it's easy to set up, break down, and change.

To populate your requirements.txt file, just type the packages you need and the version you're using. Freezing the package version is better for recreating the same environment over long periods of time and across different systems. Here's what it looks like:

matplotlib==3.9.4
numpy==2.0.2
pandas==2.3.3
scikit-learn==1.6.1
seaborn==0.13.2

If you want the latest and greatest version, just leave the version empty. This is better for recreating a set of packages you use regularly, but want to keep updated with the latest versions. Here's what it looks like:

matplotlib
numpy
pandas
scikit-learn
seaborn

* Pro Tip *: They're easier to find and update if you put them in alphabetically order.

* Pro Tip *: If you create a ton of virtual environments and worry about running out of space on your computer, you can simply delete the .venv folder when you're done using it. If you ever need that environment again, you can simply recreate it using the requirements.txt.

There are more comprehensive ways to set it up that involve commands like pip list, but to start, just include the libraries you need. When you need the more complicated version, google it.

To load the libraries to your active environment (you remembered to activate the virtual environment, right?) at the command line type:

pip install -r requirements.txt

• The first command will probably be pip however it might be pip3 depending on the environment setup
• -r tells pip install that we'll be supplying a file, not a package name
• requirements.txt is the name of your requirements file. You can name this anything you want, but to make things easier for your future self and anyone else that reads your code, I suggest you stick with requirements.txt

That's all there is to it. You now have an active virtual environment.

Just don't forget to deactivate it when you're done with it.

Next Steps

One of the major limitations with venv in my opinion is that you can't easily specify a Python version: venv uses the Python version in the runtime environment in which it was created.

You can control the Python version using venv, it's just a little more involved. You need to have the version of Python you want loaded to your system's runtime environment. If you have multiple versions of Python installed, a common way to reference the version you want is to set it up so that you call it using the version number.

For example, in our python -m venv .venv example, you could have multiple versions of Python 3, such as 3.10, 3.11, and 3.14. To run the same call with the version you want, you'd update that command to python3.14 -m venv .venv.

Personally, I'd rather be able to just specify the version in the command itself and let the package I'm using handle the details. You can do this using Conda with the command conda create -n .venv python=3.14.

I haven't developed a workflow that I like with Conda yet. When I do, I'll look into creating an "intermediate's guide" version of this post.

In Case You Forgot

• Navigate to your project directory's root folder
• Create a virtual environment
  • python -m venv .venv
• Activate it
  • Mac: source .venv/bin/activate
  • PC: .venv\Scripts\activate
• Install packages
  • pip install -r requirements.txt
• Deactivate when done
  • deactivate