Skip to main content

Python environments

If you have not read the last post about Python we strongly recommend you have a read, just for the introduction of why Python versions play a big role on the importance of environments.

In that last post, we also mentioned that installing Python directly from the main page (python.org) is not standard practice anymore. In order to have python in your computer, we recommend using a distribution software manager.

Distribution software manager

A distribution software manager (or language distribution) is a pre-packaged collection of a programming language, its core tools, and popular libraries — all bundled together to make setup and environment management easier.

Instead of installing everything separately (Python, data science libraries, version managers, etc.), a distribution gives you a ready-to-use ecosystem that’s designed for a specific purpose — like data analysis, machine learning, or scientific computing.

If we follow our previous analogy of seeing environments as a "tool box" you can think of it like buying a starter toolkit: instead of just getting the screwdriver (the programming language), you get the full toolbox — with wrenches, pliers, and screws already organized.

environment_toolbox

For Python there are different ways you can create an environment. If you already understand what an environment is, skip this and go directly on how to set them up:

NOTE:

All of the above links will also explain how Python can be installed alongside the distribution software manager.

From now on, we will assume you have installed Python. If we used one of the distribution software manager is worth mentioning that it comes with certain pre-installed basic libraries.

But what happens when you want to use Python for a specific task and need to install additional packages? For this, Python has enabled pip, a recursive acronym for "Pip Installs Packages" or "Pip Installs Python", as its package manager to automate installation, update, and package removal.

NOTE:

conda (the command to call the Anaconda distribution from your command line) is also a package manager you can use to install libraries, but is good form to use one OR the other when using environments.

However, if you are not using a distribution software, and just have a main installation of Python for the whole system, installing new packages directly into the download of Python can have difficult consequences, not to mention the upgrade of Python versions becomes really annoying.

badPythonEnv Dmitriy Zub, Dec 22, 2021. Python Virtual Environments tutorial using Virtualenv and Poetry. Place of publication: SerpApi. Available here.

This image is a beautiful, chaotic example of what happens to your global environment when we do not have order in the different paths and versions of new packages.

The old way of installing Python from the main web page to the entire system we just installed is the Global environment. We mentioned that Python is an open-source interpreted programming language that goes through constant updates. For this reason, newer libraries developed on different Python versions often conflict with libraries without the same updates, and error messages start to pop up.

environment_toolbox

To avoid this, a good practice when using Python is to use virtual environments. This environment allows for isolating package dependencies so they do not clash.

For example, you may have two projects, one for computer vision and another for Natural Language Processing (NLP). Both of them use similar libraries but in different versions of Python. We can not install both versions system-wide, but we can create isolated environments for each project.

NOTE:

These environments are called containers because they do not interact with each other. However, this is only for the system. The folders and files in your storage are all available for all the environments. This means that if you remove, add, or change a folder when you are working inside an environment, that change is permanent and will apply to all environments

Diference between environments and folders

We mention in this last note that these environments we are creating for different Python versions will not interact with each other when we are installing different libraries and different versions of libraries.

When working with Python, it helps to understand the difference between system memory (RAM) and storage memory (like your hard drive, SSD, or SD card), and how they relate to your Python environments.

Storage Memory (Hard Drives, SSDs, SD Cards)

This is your permanent memory — where your files, folders, programs, and Python environments are stored. Everything you install (like Python itself or a library) is saved here until you delete it.

Examples:

  • Your project folders (my_project/)

  • Python installations (C:\Python311\ or /usr/local/bin/python3)

  • Virtual environments (env/, .venv/, conda_envs/)

Each Python environment is just a folder stored on your hard drive that contains:

  • A copy (or link) to a specific Python version

  • Its own site-packages folder with installed libraries

  • Some configuration files

That’s how different environments can have different libraries and versions without interfering with each other — they’re stored in separate folders on disk.

System Memory (RAM)

RAM is your temporary working memory — what your computer uses while programs are running.

When you run your code in VS Code, Python loads the necessary files and data from your disk into RAM. Once you close your program or restart your computer, RAM is cleared, but your files and environments remain on the disk.

Each project has its own environment folder, so when you install or uninstall a library in one, it doesn’t affect the other. That’s because the installation only changes the files inside that specific environment’s folder on your disk — it doesn’t touch the global system files.

This is what we call environment isolation.

When Changes Become “Global”

The isolation only applies to what’s inside the environment — things like installed libraries or Python versions. However, if you modify or delete files in your project folder or environment directory directly (for example, from VS Code’s file explorer), that’s a global change to your storage.

Examples:

  • Installing a package inside a virtual environment → affects only that environment

  • Deleting a script file or folder from VS Code → permanently removes it from your hard drive (affects everything using that file)

So, environment changes (via pip or conda) are isolated, but file changes (via the file system) are always global, because they modify the actual storage on your disk.

Action Type Scope
Installing a library in a virtual environment Environment change Isolated
Switching Python versions with pyenv or conda Environment change Isolated
Editing/deleting files in VS Code File system change Global (affects storage)
Running code or loading data Uses system memory (RAM) Temporary

Things that might interest you after reading this:

Back to top