A Bird's-eye View of Python Machine Learning Packages in 2025

130 packages in three figures and a table

The great success of my story on Python Packages for Data Visualization in 2025 (that is, relatively to the six reads of my visual exploration of energy units went a bit to my head, to the point where I started thinking about writing a similar story on Python Packages for Machine Learning in 2025. I could definitely recycle the opening statement: Python’s rich package ecosystem is perhaps its greatest strength, but also an endless source of doubt for its users. And machine learning may be the domain where Python shines at its brightest.

I just needed to scale my analysis from a dozen of DataViz packages to a few dozens of machine learning (ML) packages. Granted, I do not have first-hand knowledge of all of these. I gave myself two weeks. A month later, I had a nice list of more than 100 packages (see the table below), but I was still wondering how to organize them.

I am starting to worry that my readers will get impatient. I need to reduce the scope. But the scope is expanding daily, with new agentic frameworks popping up like mushrooms. Or are they out of scope? Maybe Python Packages for Machine Learning in 2025 should be a series. Let this story be a teaser for the future series. In this teaser story, let us zoom out and keep things visual.

Overview

So what do we see when we zoom out enough to look at the Python ML landscape as a whole? Lots of individual packages of different sizes, which to some extent can be aggregated in clusters. Here is my go at it:

Clustering machine learning packages in a meaningful way is no easy task. Starting from the different paradigms (supervised, unsupervised, reinforcement learning) — as one often does when sketching machine learning as a field — does not seem very productive here, given the overwhelming share of supervised learning in applications. A split by task may be slightly better, but most packages support a multitude of tasks. A split by algorithm would suffer from the same issue. Many packages do focus on neural networks, and a handful on gradient boosting only.

Clustering packages by modality does yield a few well-defined clusters, especially around natural language processing and computer vision. Still, some packages are focused on aspects totally orthogonal to the above dimensions, such as interpretability, experiment tracking or model deployment. There is also this whole spectrum from low- to high-level frameworks:

• low-level frameworks offering the user primitives to flexibly implement algorithms, such as JAX, which basically offers automatic differentiation and just-in-time compilation and lets you take care of the rest;
• higher-level frameworks offering larger building blocks, such as Keras and its predefined layers
• libraries that offer ready-to-use models, such as the HuggingFace Transformers library
• and even commoditized models made accessible via APIs, the OpenAI interface being the reference for large language models.

The clusters I ended up defining for the figure above cut across these different dimensions to build more-or-less meaningful lumps.

A Timeline

The landscape sketched in the previous paragraph is a dynamic, ever-expanding landscape.

The following timeline shows release dates: the first for each package as a pink circle, the latest as a blue circle, the ones in-between as small purple dots. The repository creation date (pink triangle) and the date of the latest push to the repository (blue triangle) are also shown as a reference.

The packages are sorted by the date of repository creation, so that the longest-serving packages, starting from the Natural Language Toolkit (NLTK), are on top, followed by newer classics in the middle, and some shiny newcomers at the bottom. A few unmaintained packages are betrayed by blue dots appearing left of the right end of the figure. The attentive observer will also notice an outlier with the first release date of Huggingface datasets. Looking at the PyPI history of the package, it seems that the datasets name had served for a another package in a previous life on PyPI.

Dependencies

Packages are not islands. Some people even talk about software ecosystems. In particular, most packages depend on other packages to fulfill essential or optional functions. I wrote about visualizing the dependencies of Python packages in another story, which shows that dependency networks can be quite tangled. In this third figure, I am just representing a small subset of the big dense network of dependencies between ML and other packages, in matrix form.

Main takeaways:

• an overwhelming majority of machine learning packages directly depend on NumPy, and many on SciPy. Mastering these two libraries might still be a good idea if you want to make optimal use of ML packages.
• It looks like PyTorch and scikit-learn are the ML packages on which other ML packages depend the most.
• Dependencies between ML packages are often indirect and/or optional. For example, the important Transformers package (on which quite a few packages depend) optionally depends on TensorFlow, keras and JAX.

Appendix

How did I come up with these packages?

Every package discussed here had to fulfill the following criteria:

• be a Python package available on PyPI;
  • this excludes quite a few popular repositories corresponding to learning resources, lists, tutorials or paper implementations without a standalone Python package
• have a public repository available on GitHub;
• have an English description and an English README on GitHub, as I unfortunately cannot read Chinese;
• be focused on machine learning or one of its subdisciplines, excluding data-related topics without a learning component (such as projects related to data-engineering) and supporting tools with a more general purpose (such as scientific computing or dashboarding);
• have a minimum degree of popularity, as demonstrated for instance by 1000 GitHub stars or more.

The GitHub API helped in compiling the list, but a lot of manual work also went into it.

Table

The following table summarizes the dates of repository creation and initial PyPI release, along with the number of GitHub stars and the average number of PyPI downloads in the last three months (as obtained from the pypistats.org API). You can sort the table by any of these fields.