Affiliated projects and packages

Table of contents

In the following, projects that work closely together with Scikit-HEP are described. They extend the Python ecosystem in HEP and remain, due to their size and scope, generally independent of Scikit-HEP. In most cases, at least one Scikit-HEP core developer is on the maintainer team or regularly contributes to these packages. These packages are highly recommended for Scikit-HEP developers and users.


GooFit: GPU/OpenMP fitting in Python and C++.

GooFit is a powerful, fast fitting library designed to mimic the familiar syntax of ROOT’s RooFit. The code and installation instructions are available here, on GitHub, and a description of the fitting process and API is available on GitHub IO.


zfit: Scalable Pythonic fitting

The zfit project brings together the different model fitting efforts in Python for HEP by providing a stable API and workflow. The implementation of the fitting library is based on TensorFlow, a deep learning framework built for high performance computing on modern architectures, which is mostly hidden to the user. While traditional functionalities such as loading ROOT-files or using the Minuit minimizer are integrated in zfit, the library is completely independent of the ROOT project and has no dependency on it thanks to Scikit-HEP packages.

zfit uses a class-based approach for every part in the workflow and contains convenient base classes that allow for simple customization. Moreover, zfit offers extensive model building, composition and customization capabilities.

The project consists of additional libraries extending the capabilities of the core package.


cibuildwheel: A utility for building all PyPI supported binary wheels on all CI systems. See our guide for instructions.

The cibuildwheel project provides a Python package that can be installed on CI systems to build Python wheels. All wheels possible for an OS are built, using best practices for installing Python for building compatibly. Extensive environment variable configuration allow exact version specification, manylinux wheel selection, tests, and much more. Specialty architectures and PyPy are also supported.

This replaces the azure-wheel-helpers repository that was previously used to build wheels for Scikit-HEP. For up-to-date instructions, check the Scikit-HEP developer pages.


conda-forge ROOT: CERN’s ROOT on Conda-Forge.

CERN’s ROOT framework traditionally has been difficult to install – several hours on a single core, with many dependencies. The situation is better than it used to be, it is easier to build and available in more places, but Python was still a challenge; ROOT is linked to just one version of Python, and the one you get with pre-built ROOT can often be the wrong one. And, if you use the Conda Python distribution , which is a popular choice for Scikit-HEP users, the official ROOT team recommendation for building it on top of the Conda stack was: too hard, don’t do it. But now, the ROOT Conda-Forge package provides a fully featured ROOT binary package for macOS or Linux, fully integrated into the Conda environment system!

The Conda-Forge ROOT project has been developed by Scikit-HEP admins and is used in the Continuous Integration (CI) system of several of our packages to ensure consistency and interoperability with ROOT. It is used or intended to be used in our ROOT-based packages, like root_numpy. Analysts can create an environment with ROOT by the following trivial environment.yml file, often used to create tutorials on binder:

name: uproot_and_root
channels:
  - conda-forge
dependencies:
  - python
  - jupyterlab # Interactive environment
  - root       # Conda-Forge ROOT
  - uproot     # Can be mixed with other Scikit-HEP packages

pybind11: A C++11 API for CPython and PyPy. Can create extension modules written purely in C++ or in C++ and Python; no new language, separate generation step or tooling required (header only templated C++).

The pybind11 project provides a clean and familiar interface between Python and C++. Unlike the project that inspired it, Boost.Python, it is header only, depending only on C++11 features and works with any build system, including setuptools and CMake, without adding any dependencies. Unlike Cython, there is no new language required - you’ll just be working in vanilla C++11. Unlike SWIG, you can build up your bindings one part at a time, adding Pythonizations or custom interfaces. And unlike ROOT or cppyy, it creates compiled binaries that are easy to distribute without requiring extra user dependencies (though those tools can bind templates without specializing them as a result). It also supports going the other direction and embedding Python in a C++ application.


repo-review: A Python 3.10+ framework for running configuration check plugins.

This is a framework for building checks designed to verify that a repository follows guidelines. By itself, it does nothing - it requires at least one plugin to be installed.

With one or more plugins, it will produce a list of results - green checkmarks mean this rule is followed, red x’s mean the rule is not. A yellow warning sign means that the check was skipped because a previous required check failed. Four output formats are supported; rich, svg, html, and json.

sp-repo-review provides checks based on the Scientific-Python Development Guide at scientific-python/cookie.