# skore: a support grid that skips the oldest release on the newest Python

> Skore is Probabl's open-source Python library for structured machine learning evaluation, positioning itself as a conductor over generic tooling rather than a replacement for it, with a hosted platform as its commercial half. Two things on the page are more specific than the pitch. The support grid drops the oldest scikit-learn on Python 3.14 and names no macOS at all, and the quick start generates a hundred thousand samples, which is heavier than a first run on a laptop usually wants to be.

**probabl-ai/skore** — Track your Data Science. Skore's open-source Python library accelerates ML model development with automated evaluation reports, smart methodological guidance, and comprehensive cross-validation analysis.

- Repository: https://github.com/probabl-ai/skore
- Website: https://docs.skore.probabl.ai
- Stars: 673 · Forks: 141
- Language: Python
- License: MIT
- Published: 2026-09-10 · Updated: 2026-09-10 · Language: en
- Canonical page: https://hysenlabs.com/projects/probabl-ai-skore

## The distribution lives in a subdirectory, so the Makefile uses a relative path

There is no manifest at the root of this repository. The top level is sixteen entries and the package is not one of them directly: there is a directory called skore, and that directory is the distribution.

The Makefile shows the consequence. Every install target installs from that subdirectory by relative path, installing it editable along with three extras named test, sphinx and dev, and then installing the pre-commit hooks. The test target then changes directory into the package before running pytest.

So both make targets assume you are standing at the repository root, and there is no root-level manifest to point a tool at. A repository where the package is the root is the common case; here the root is a workspace with one member.

The other root entries are more than one would expect for a single-package project: a pre-commit config, an agent instruction file, a release process document written as reStructuredText, a continuous integration directory, a documentation directory, a separate sphinx directory, a spell-checker configuration, and a Makefile.

Two of those overlap in purpose. There is both a docs directory and a sphinx directory, and the README's own image assets are loaded out of the sphinx directory, which suggests one holds the source and the other the build output or the theme.

## The support matrix skips the oldest scikit-learn on the newest Python

The support section is a full grid rather than a range, and reading it as a grid shows one asymmetry.

The stated envelope is at most four versions of Python and at most four versions of scikit-learn, tested on Linux and Windows. The Python versions are 3.11, 3.12, 3.13 and 3.14. The scikit-learn versions named are 1.6, 1.7, 1.8 and 1.9.

The grid is complete for three of the four Python versions. On 3.11, 3.12 and 3.13 the tested scikit-learn versions are 1.6 and 1.9, two per row. On 3.14 they are 1.7, 1.8 and 1.9, three per row, and the oldest of the four is absent.

So the newest Python drops the oldest scikit-learn and tests three consecutive releases instead of the two endpoints. That is a normal consequence of a new interpreter landing after a library release, and stating the grid rather than a range makes it visible rather than implied.

The second asymmetry is the platform list. Linux and Windows are named, and nothing else is. There is no macOS row, in a project whose quickstart uses scikit-learn and whose stated audience is data scientists, most of whom work on macOS.

The recorded state is MIT licensed, Python, the main branch, not archived, and the last recorded push is 2026-10-02, which is the current date.

## The quick start builds a hundred thousand samples

The getting-started example is nine lines long and one of the values in it is worth pausing on.

```python
from sklearn.datasets import make_classification
from sklearn.linear_model import LogisticRegression
from skore import CrossValidationReport

X, y = make_classification(n_classes=2, n_samples=100_000, n_informative=4)
clf = LogisticRegression()

# Get structured insights that matter for your use case
cv_report = CrossValidationReport(clf, X, y)

# See what insights are available
cv_report.help()

# Example: Access the metrics summary
metrics_summary = cv_report.metrics.summarize().frame()

# Example: Get the ROC curve
roc_plot = cv_report.metrics.roc()
roc_plot.plot()
```

The dataset is generated with a hundred thousand samples and four informative features, split into two classes, and the classifier is a plain logistic regression. The point of those choices is that the report, not the model, is the subject: with that many samples every fold has enough data for the metrics to look stable.

That works. It is also a heavier default than a reader on a laptop expects from something labelled a quick start, and the sample size is the kind of thing that makes a first run look like a hang.

The API shape is the more durable part of the example. One constructor takes the estimator and the data and returns a report object. That object has a help method, which is the discoverability mechanism: instead of a separate API reference you ask the object what it can tell you.

Then the accessors are namespaced by what they describe rather than by what they do, with a metrics group holding a summarize that converts to a dataframe and a roc that returns a plot object with its own plot method.

## Three extras, and a separate long-term-support install lane

The install section offers three variants and they differ by what they pull in rather than by what they enable.

```bash
# If you plan to use Skore locally
pip install -U skore
# If you wish to interact with Skore Hub as well
pip install -U skore[hub]
# If you wish to log projects to MLflow
pip install -U skore[mlflow]
```

The plain install is for local use. A hub extra adds the ability to interact with the hosted platform. An mlflow extra adds experiment logging to an external tracker. So the three are: nothing extra, the vendor's own platform, or a third-party tracker.

The Makefile reveals a fourth and fifth variant that are not on that list. There is a normal editable install with test, sphinx and dev extras, and a second target for a long-term-support lane that swaps the test and sphinx extras for separate long-term-support ones.

That second target is the interesting one. A dedicated install lane with its own extras implies a dependency set held back from the main one, which is the standard way to keep testing against older pinned libraries without holding them for everyone.

Conda is offered as a peer rather than an afterthought, installed from the forge channel, with a link to the version listing. The version requirement given before any of it is Python 3.11 or newer, matching the bottom of the support grid.

## The library is half of a product whose other half is not in the repository

The page describes itself as a library and then immediately describes a platform, and the repository contains only the first.

The core mission is stated as turning uneven machine learning development into structured decision-making, and it says that consists of two complementary components. The library is the open-source part described on this page. The hub is a collaborative platform where teams share, compare and build on each other's experiments, with a link to a product page on the vendor's site.

That split explains the extras. The local install is the library with nothing added; the hub extra is the library with the ability to talk to the platform. The open-source half is the part you can run entirely on your own machine, and the extra is the bridge to the part you cannot.

The positioning paragraph is also worth reading for what it names. The page frames itself as a conductor over three specific libraries: two tabular libraries for data exploration, one for stateful transformations, and scikit-learn for training and evaluation. Those are described as generic tools that accommodate a wide range of use cases, with the gap being that choosing between them and maintaining structure is the reader's problem.

The claim being made is narrow and checkable: fewer lines of evaluation boilerplate, structured project layout, and methodological warnings built in rather than looked up.

## Examples carry their own lint config and a directory named for pitfalls

The examples directory has eight entries and two of them tell you how the project treats its own documentation.

There is a lint configuration file inside the examples directory, separate from whatever the library uses. Two ruff configurations in one repository means the examples are held to a different standard from the package, which is a reasonable thing to want and an unusual thing to see committed.

There is also a directory called for pitfalls and solutions, sitting alongside directories for getting started, integrations, model evaluation, technical details and use cases. That directory is the physical counterpart to one of the four claims on the page, the one about built-in methodological warnings helping you avoid common problems.

The other four categories map onto the page's own structure. Getting started and model evaluation cover the quickstart path, technical details is the API surface, use cases is the application stories, and integrations is the third-party boundaries the extras describe.

The examples also have their own readme, as a plain text file rather than markdown, which is the smallest possible sign that they are maintained as a set rather than appended to.

## Release tags are namespaced for a repository with one distribution

The release tags have an unusual shape. The three most recent are a version, then a patch release, then another patch release, and each tag carries a prefix naming the package.

So a single-distribution repository is tagging releases as if it were a workspace. The prefix is consistent across all three entries, and the naming convention means the tag string is not a bare version number.

That is harmless in practice and helpful in a different shape of repository. It is also a small reminder that this layout came from a workspace-shaped habit: the package lives in a subdirectory, the Makefile installs it by relative path, and the tags are namespaced, even though there is exactly one thing to release.

The cadence itself is unremarkable and worth stating plainly. One patch and one minor release inside three weeks, with the minor following the patch by a week.

The recorded popularity is the outlier on this page. Alongside the usual counts there is a large number of open issues, which for a project whose primary documented purpose is reducing friction is the metric most worth watching, since the whole pitch is that people will file fewer of them.

## Conclusion

Use this if you are already using scikit-learn and want evaluation reports and methodological warnings without writing the boilerplate, since the report object can describe its own capabilities and the accessors are named after what they describe. Skip it if you are on macOS, because the support section names Linux and Windows only. Before you run the quick start, read it, because a hundred thousand samples on a laptop is a heavy first impression of a library whose pitch is saving you time.

## FAQ

### What is Skore used for?

Active learning and structured evaluation for machine learning work. It generates evaluation insights from a model and data in one line, reduces evaluation boilerplate, provides built-in methodological warnings about common pitfalls, and keeps project structure organised. The page frames it as a conductor over generic libraries rather than a replacement for them.

### How do I install skore?

Python 3.11 or newer is required, and a virtual environment is recommended. Then install the plain package for local use, the hub extra to also interact with the vendor's hosted platform, or the mlflow extra to log projects to an external tracker. A conda-forge channel package is also available.

### Which Python and scikit-learn versions does skore support?

It is tested on Linux and Windows, across Python 3.11, 3.12, 3.13 and 3.14. Python 3.11, 3.12 and 3.13 are each tested with scikit-learn 1.6 and 1.9, while Python 3.14 is tested with 1.7, 1.8 and 1.9, so the oldest scikit-learn is skipped on the newest interpreter.

### What is Skore Hub?

The collaborative half of the product, described as a platform where teams can share, compare and build upon each other's structured experiments. The open-source library described in this repository is the other half, and the hub extra is what lets the library talk to the platform.

### How do I get a model evaluation report with skore?

Construct a cross validation report with the estimator and the data, then call its help method to see which insights are available. Metrics are reached through a namespaced accessor, with a summarize method that returns a dataframe and a roc method that returns a plot object.

## Sources

- [License: MIT](https://github.com/probabl-ai/skore/blob/main/LICENSE)
- [probabl-ai/skore on GitHub](https://github.com/probabl-ai/skore)
- [Project website](https://docs.skore.probabl.ai)
- [README](https://github.com/probabl-ai/skore/blob/main/README.md)
- [Releases](https://github.com/probabl-ai/skore/releases)

---

Hysen Labs editorial analysis, written from the project's own repository and release notes. Cite the canonical page: https://hysenlabs.com/projects/probabl-ai-skore