From time to time you and I are lucky enough to start fresh. A new MacBook, a new Linux laptop or maybe a new server?

And of course, we need to quickly get it up and running to create lovely plots. With Anacoda, Conda, Mamba, UV, Python, Virualenvs and more it can get confusing quickly.

While all of this will be changing over time, today I want to disentangle this status quo as of Summer 2025 and maybe create a bit of order in this chaos.

This is my personal view and is heavily influenced by my own experiences and preferences. There are many more ways to get to a Python environment.

Python - How to get it

While with macOS you usually start without Python, if you are running Linux (Ubuntu, Debian, Fedora etc.), chances are that you already have Python installed on your system the moment you log in. But that’s not the Python we use for our scientific work. Why is that?

The Python that comes bundled with the distro is the version needed by the system to run. If we meddle with that, we might break the system. Consequently, people usually install a separate Python.

So how do you get Python?

Well, this depends on what you want to do, but whatever you do please don’t download it from python.org, except if you know why you are doing that.

Using Virtual Environments

NOTE: I exclude conda from this section, as I will talk about it more later.

If you only need Python and Python dependencies (such as Jupyter), you might want to use virtual environments.

Those are basically small Python installs in a folder (usually .venv) in the project folder you are working on. And they can be activated and deactivated.

To manage such project-specific Python environments, you can use multiple tools. As of summer 2025, I prefer using UV from Astral. But other tools exist, such as virtualenv or venv.

I like using UV for my Python-only projects, as it makes the installation of new environments easy, but if you decide to use conda (see below), you don’t really need to use it, as conda can do everything UV can do.

Using UV

UV is a “Python package and project manager” that is being developed by a company called Astral. It is open source, but the company is a for-profit venture capital-backed business, as far as I understand. So there is some risk attached to using UV.

To install UV, Astral provides instructions on their webpage: Install UV

After that is done we can use it.

If you are in your Python project folder, maybe it’s a package or maybe it’s a folder with scripts and notebooks, you can simply create a new environment with UV:

uv venv -p 3.12
source .venv/bin/activate

And now there is a new clean Python install active in your terminal.

If you now want to install packages in there you can run for example:

uv pip install jupyter
# or
uv pip install -r requirements.txt

And this way Jupyter and JupyterLab are available from this specific environment.

which jupyter-lab
# /home/USER/EXAMPLE/.venv/bin/jupyter-lab

That’s pretty cool. And if you mess it up and something breaks, you can simply delete it and reinstall it all:

rm -rf .venv
uv venv -p 3.12
source .venv/bin/activate
uv pip install -r requirements.txt

And suddenly messing up your Python is not that bad anymore.

But what if you want to use other tools? Maybe you have to use R? Then UV is not the answer.

One Step up: Conda

Conda was created to solve the package and virtual environment issues for data scientists. It allows us to not only to install Python but also R and all of the R packages from CRAN and other sources.

If you imagine that virtual environments are small Python installs, then conda environments are more like a new operating system. It can provide an environment-specific Python, but also a host of other tools (e.g. bwa, samtools, etc.) and libraries (e.g. numpy, pandas, etc.).

Anaconda

A lot of people first interact with Python and conda via Anaconda. Anaconda, like Astral, is a company that develops the core component of the conda package manager. They also provide a distribution of conda called Anaconda. This distribution comes with a lot of packages pre-installed. This is great for getting started, but they have since changed their licensing model, and the distribution is no longer free for commercial use.

Conda-Forge

Conda-Forge is a community-driven alternative to Anaconda. It is a collection of recipes, build tools, and distributions and while they don’t provide the same level of support as Anaconda and also don’t have a fancy user interface (GUI) App, they provide an amazing distribution (miniforge) that everyone can use for free.

Mamba: If you are wondering what the difference between conda and mamba is, mamba is a faster implementation of conda. So everywhere people write conda you can also use mamba. I will be using conda in this blog post, but it all applies to mamba as well.

Installation

To get setup with miniforge I recommend going to their Github and following the instructions there, as they do change from year to year.

Using Conda

There are a few tricks to using conda that one has to know to not mess everything up.

As already described conda environments can hold all sorts of software, and especially can hold software that is a different version to the one on your computer or in other environments. But notably, each conda environment can only hold one version of Python and for that matter one version of any software (with exceptions).

That means you can not create a conda environment that has Python 3.10 and Python 3.11 installed. If you try that you will see an error:

conda create -n python311_312 "python==3.11" "python==3.12"
# [...]
# PackagesNotFoundError: The following packages are not available from current channels:
#
# - python[version='==3.11,==3.12']

This is a key concept to remember and often the source for much trouble for beginners. When deciding to create a new conda environment you have to decide which version of Python you want to use and stick to it. You should not change it later.

Right now you will be well served to create Python 3.12 environments.

Channels

Let’s take a step back and configure our new conda install. Conda uses so-called channels. Each Channel is a repository of software that can be installed. The default channel is called defaults and you can only use it with an Anaconda license. As we use the miniforge defaults is not configured, but just take care when copy-pasting commands from the internet.

To configure channels for your machine you can edit the file ~/.condarc and add the following lines:

channels:
 - conda-forge
 - bioconda

This will ensure you use the conda-forge and bioconda channels by default. You can always override this by specifying the channel in the command line.

Managing environments

With conda configured, we can create environments. Environments are isolated spaces where you can install software. This is useful to avoid conflicts between software packages. For example, you can have one environment for Python 3.12 and another for Python 3.11.

Creating a new environment is easy and can be done by running:

conda create -n myenv python=3.12

This would create a new environment called myenv with Python 3.12 and nothing else in it.

You can then activate the environment by running:

conda activate myenv

And you can then install all sorts of software in it:

conda install bedtools

Now comes the messed-up part. You can also use it to install Python packages. And here it gets tricky and you will need to decide if you want to use conda, pip or uv.

For example if you want to use conda to install numpy you can do:

conda install numpy

This will also install some non-Python dependencies of numpy and that’s pretty cool:

Package         Version  Build                 Channel           Size
─────────────────────────────────────────────────────────────────────────
Install:
─────────────────────────────────────────────────────────────────────────
+ libblas         3.9.0  31_h59b9bed_openblas  conda-forge     Cached
+ libcblas        3.9.0  31_he106b2a_openblas  conda-forge     Cached
+ libgfortran    15.1.0  h69a702a_2            conda-forge     Cached
+ libgfortran5   15.1.0  hcea5267_2            conda-forge     Cached
+ liblapack       3.9.0  31_h7ac8fdf_openblas  conda-forge     Cached
+ libopenblas    0.3.29  pthreads_h94d23a6_0   conda-forge     Cached
+ numpy           2.3.0  py312h6cf2f7f_0       conda-forge        8MB
+ python_abi       3.12  7_cp312               conda-forge     Cached

But if you were to use pip for this install, you still install numpy but instead of getting it from conda-forge you get it from PyPI (the Python Package Index).

pip install numpy
Collecting numpy
 Downloading numpy-2.3.0-cp312-cp312-manylinux_2_28_x86_64.whl.metadata (62 kB)
Downloading numpy-2.3.0-cp312-cp312-manylinux_2_28_x86_64.whl (16.6 MB)
 ━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━ 16.6/16.6 MB 14.0 MB/s eta 0:00:00
Installing collected packages: numpy
Successfully installed numpy-2.3.0

And thirdly if you now got hooked on UV you could install UV first and then use it to install numpy:

mamba install uv
# or
pip install uv
uv pip install numpy

And suddenly you have three ways of managing your conda Python environment.

Luckily all these tools, in my experience of 2025, seem to mostly respect each other but even then I was able to create a broken environment pretty quickly.

So it is best, to choose one of those 3 methods and use that to install your Python packages.

If you wonder how I broke my environment, I installed numpy with mamba, which installed version 2.3. I then installed numpy with UV as version 2.2. And then tried to upgrade numpy with conda to 2.3 and that then said I had already 2.3, which I do not. So now I could not upgrade with conda, but would have to use UV to get 2.3 back again.

If you broke your conda environment, you can always delete it and start over. Deleting is as easy as running:

conda deactivate
conda remove -n myenv --all

Package managers and Homebrew

Going one more step up the stack there are package managers. On linux they are called apt and dnf and on macOS there is a tool called brew (homebrew). These allow you to install software on your machine without any environment management.

So essentially they tread your entire machine as a single environment. So you can only have one version of a package installed at a time.

I would not recommend using those to install Python packages, but it is a good tool to have in your tool box to install packages you want to have once and available across your whole machine (like git).

This concludes my take on the Python package management in 2025.