Cailean Osborne

This post was originally published on the Probabl blog.

scikit-learn is one of the most widely used tools in data science, counting over 200 million downloads every month. You may know it as the Python library, but behind the code there is a global community that develops, maintains, and sustains it for the benefit of all data scientists all over the world.

Community Voices is an interview series where we introduce you to members of this community – maintainers, contributors, educators, community-builders, and many others. Each month we’ll sit down with a different person to hear how they got involved in scikit-learn, what they’re working on, what they’re excited about, and how newcomers can get involved.

Community Voices continues Reshama Shaikh’s (@reshamas) interviews with scikit-learn contributors, which have been published on the scikit-learn.org blog since 2017. Reshama no longer has the time to continue these interviews and, after syncing with her, we decided to jump in and continue her tradition.Thank you, Reshama, for all your work over the years — we’re honored to pick up where you left off!

Interview with Lucy Liu

To kick off Community Voices , we’re delighted to speak with Lucy Liu (@lucyleeow), a scikit-learn core maintainer and software engineer at Quansight Labs. Lucy has led much of the work bringing array API support to scikit-learn. Longtime readers of the scikit-learn blog will recognize her: Reshama interviewed Lucy back in 2022, and Lucy published an update about array API adoption in scikit-learn in March this year.

So it’s a pleasure to catch up with Lucy and hear about what she’s working on now.

Cailean: Hi Lucy! Please tell us a bit about yourself.

Lucy: I currently live in Australia and am a software engineer at Quansight Labs. I primarily work on scikit-learn but also contribute to or have contributed to Sphinx-Gallery, array-api-strict and napari. My introduction to programming came through R, which I used for bioinformatics research during my master’s degree. It became clear to me fairly early on that I was more interested in software and tool development than biomedical science. Luckily I was able to transition to more software focused roles. At Quansight Labs I get to work alongside many other maintainers in the scientific python ecosystem, helping improve the software that researchers and data scientists rely on.

GitHub: @lucyleeow LinkedIn: @lucy-jp-liu

Cailean: How did you first get involved in scikit-learn?

Lucy: Unlike many contributors who were users first, I started working on scikit-learn via my role at INRIA, where many scikit-learn core developers used to work. My role involved working on RAMP, a platform for collaborative data science, and contributing to open source. I saw the latter as an amazing opportunity to both contribute to the ecosystem and learn from talented open source maintainers, particularly as I had only authored small solo packages previously.

I started with contributing to Sphinx-Gallery, which was a great introduction as it is a small project. Later, I also began contributing to scikit-learn, where I could combine my interests in statistics and software engineering. I’ve continued maintaining both projects ever since.

Cailean: How would you explain the value of scikit-learn for data scientists to a non-technical reader?

Lucy: scikit-learn offers a complete toolkit for the data analysis pipeline, from data preprocessing to model training, model evaluation, and visualization. There are three things, in my view, that make it valuable.

First, the documentation, which provides clear explanations, sound guidance, and useful references.

Second, its judicious balance of choice and flexibility. scikit-learn has been very deliberate about what is included, favoring algorithms that are old enough to be stable and cited often enough to be broadly considered reliable, standard methods. This avoids overwhelming the user with choice, while still providing an ecosystem of extensions (e.g., scikit-learn-extra) for niche and expert needs.

Finally, it is thoroughly tried and tested. The large user base, long history, and dedicated maintainers means that most bugs have been fixed or at the very least documented.

Cailean: Tell us about a scikit-learn feature that you’ve developed and that you’re proud of. What is it and why does it matter for data scientists?

Lucy: This would definitely be adding array API support to scikit-learn metrics and estimators. scikit-learn was originally written for NumPy which is geared towards single-core CPU execution. With array API support however, users can pass arrays from any array library implementing the standard, including PyTorch and CuPy. This makes scikit-learn more flexible, allowing users to benefit from array library features, namely GPU acceleration, with almost no change in their code.

Since this work spans much of the codebase, it has prompted us to look at the code holistically and make improvements beyond array API support. It has led to refactoring, increased consistency and improved testing structure. Although these improvements are not always visible to users (and are rarely glamorous), it’s invaluable for keeping a large, long-live project like scikit-learn healthy over the long term.

Cailean: What’s your top priority for the coming year that data scientists should watch out for?

Lucy: Continued work on adding array API support, particularly around testing infrastructure and defining consistent and predictable behavior when arrays come from different libraries. For example, for cost efficiency a user may want to train a model on a GPU-backed array but use a CPU-backed array to make predictions. The goal is to make scikit-learn more flexible while ensuring its behavior remains predictable and unsurprising.

Cailean: I know an important topic for you is the community and supporting contributors. Could you share what you think it means to have a healthy open source community and how you’re going about that in scikit-learn?

Lucy: Every open source community looks different, but in scikit-learn I believe a healthy community is one that supports and mentors new contributors, some of whom eventually become maintainers themselves. This ongoing growth is essential, as maintainers naturally move on over time - whether they finish their PhD, take on new commitments, or their interests shift elsewhere.

Now that LLMs have made opening pull requests (PRs) quite easy, it’s become clear that we need to be more intentional in identifying people who are genuinely interested in contributing to the scikit-learn community. This is something we are still grappling with, similar to many other open source projects.

We have spent more time thinking about what we want the contributor pipeline to look like and have made several changes to support this. This includes updating our contributing documentation to highlight the value of non-code contributions and encourage contributors to work on issues they genuinely care about, instead of “good first issues” which don’t arise often. Contributing to a large project often requires significant effort and waiting for reviews, so we think it’s better when contributors are motivated by the problem they are solving. We have also clarified which issues are ready for contributions and added a section to our PR template where new contributors can introduce themselves. This helps us build relationships with human contributors, and minimize time spent on unsupervised LLM-generated contributions.

Cailean: If you could make 1 recommendation to a new contributor seeking to get involved in the scikit-learn community today, what would it be?

Lucy: Take some time to review pull requests (PRs)! It is a great way to learn the project’s norms, both in terms of the codebase and community interactions. It also helps you appreciate the effort involved in reviewing PRs and understand how you can make the process easier for reviewers as an author.

Contribute to Community Voices!

Community Voices celebrates all contributors to scikit-learn – present and past, technical and non-technical. If you’d like to contribute, please go ahead and get in touch by creating an issue in https://github.com/scikit-learn/blog/issues

Stefanie Senger

This blog post is a cross-post of a Probabl blog post and based on a talk given at EuroSciPy 2026 in Kraków (slides).

Metadata routing has been introduced gradually in experimental mode since scikit-learn 1.3; coverage is now almost complete, and the feature is mature enough that users can use it in real workflows.

What is metadata routing?

In scikit-learn, metadata is data you want to apply on top of your tabular features and your target. It influences how a function treats X and y.

You may be familiar with two common kinds of metadata from scikit-learn: sample_weight and groups. In addition to these, libraries such as fairlearn expose their own kinds of metadata, and you can define custom metadata to be used in business logic, for instance. The benefit of using metadata is usually not a higher score on the model, but a more realistic or better tuned model to begin with.

Routing is the mechanism that passes that metadata between several components of a pipeline to where it is finally used (“consumed”). Before the routing API, using metadata was only possible in limited cases. With routing enabled, you can pass sample_weight and groups through nested meta-estimators, combine third-party objects with scikit-learn estimators while still forwarding their metadata, and define custom metrics, scorers, and estimators that consume metadata you invent yourself.

The Metadata Routing API is a potent and flexible tool that allows users to define in detail where their metadata gets used. It enables new use cases and enhances interoperability with third-party libraries. The adoption of the routing API is spreading in the ecosystem, for example in fairlearn, imbalanced-learn, skada, skorch, and skfolio.

Metadata in the wild

Let’s walk through an example.

Imagine a medical study on the effectiveness of a new treatment. Here we have observational data that is getting used in that study. Features include “sex”, “age”, “severity”, and whether a patient received a medication; the target is the “recovery time”. This data is naturally biased, because it does not come from a randomized trial. It entails all the imbalance and structure that real world data usually implies.

Figure 1: Table of data and target for our example study.

Patients come from different hospitals that differ in systematic factors such as medical devices, policies, and the socioeconomic mix of patients. A sample’s provenance from a certain hospital is useful for evaluation, but it is not a feature we want the model to treat like “age” or “severity”. Instead we keep it as groups with shape (n_samples,), but separate from X.

Figure 2: Table of data and target with an additional groups metadata.

During cross-validation we want a realistic estimate of how well a model can generalize. If samples from the same hospital appear in both the training and validation fold, the model can look better than it will on a new hospital, which is a form of data leakage.

Instead of allowing data to be leaked, we use the metadata groups that we pass into cross-validation. scikit-learn’s GroupKFold keeps each group entirely in either the train set or the validation set for a given fold:

Figure 3: Training and validation set after splitting with GroupKFold.

Passing groups into cross_validate together with a grouped splitter has worked in scikit-learn for a long time and keeps functioning the same way:

from sklearn.model_selection import GroupKFold, cross_validate
from sklearn.linear_model import Ridge

ridge = Ridge()
cv = GroupKFold(n_splits=2)
cross_validate(ridge, X, y, cv=cv, groups=groups)

For our patient data set, sample_weight draws the model’s attention toward (or away from) particular samples. It can be used if biases refer to how features are distributed or relate to one another. For instance, if we suspect that race, age or socioeconomic status of a patient determined if they got the new treatment at all, sample_weight can re-balance the over- or under-representation of a certain group of patients and draw the model to emphasize reducing training error on the higher weighted samples more.

One method to determine sample_weight values is inverse probability of treatment weighting (IPTW) in observational studies (see Florian Wilhelm, Causal Inference and Propensity Score Methods (walkthrough with scikit-learn)). Probabl Whiteboard Series has also published an exploration on the usefulness of sample_weight from a different angle (see Improving models via subsets).

In practice, since Ridge.fit can consume sample_weight, you might reasonably try:

cross_validate(ridge, X, y, cv=cv, sample_weight=sample_weight)

…and hit a wall:

TypeError: got an unexpected keyword argument 'sample_weight'

In practice you often nest further. Maybe you want to cross_validate around a GridSearchCV that tunes Ridge, with a scorer that can also take sample_weight and a GroupKFold that needs groups. Before routing, that stack failed: cross_validate had no way to forward sample_weight into the nested fit and score calls, even though those methods support it. The same limitation blocked metadata from many third-party libraries when combined with scikit-learn’s cross-validation tools.

If we want fairer, less leaky models to predict the treatment effect for future patients, we need metadata to move through several layers of other tools by contract. Metadata Routing API was built to bridge exactly this gap: you can use it to get your metadata to be used inside the functions that consume it.

Using the metadata routing API

With metadata routing, the code stays close to what you already know. The orange boxed snippets show you what you need to add to take advantage of the routing in experimental mode:

Figure 4: The three metadata routing steps: enable, pass at the top, request metadata where it gets used. See Metadata Routing in scikit-learn User Guide for a full example.

1. Enable the experimental feature. set_config(enable_metadata_routing=True) turns routing on. Disable it when you no longer need it.
2. Pass metadata once at the top-level tool (here cross_validate). That top-level object could also be a Pipeline or a meta-estimator (an estimator that takes another estimator as an argument).
3. Request metadata where it should be consumed, with set_*_request (set_fit_request, set_score_request, and so on). Grouped splitters such as GroupKFold already request groups by design, so you do not set that yourself.

In experimental mode, users need to use set_*_request methods everywhere a metadata can be consumed. These methods exist to grant users maximum flexibility. In future releases, these will come with default settings, so that users in the most common use cases don’t need to touch them anymore.

This is the core mental model: pass at the top, request at the leaves.

Pipelines that transform validation sets

Metadata routing also unlocks a new feature that was impossible before and rescues data scientists from awkward workarounds: validation sets that are transformed alongside X in a Pipeline.

Some estimators such as HistGradientBoostingClassifier can split off a validation set inside fit for validating early stopping. If used in a Pipeline with preprocessing steps that were applied on the full matrix, that internal split leaks information from the train set into the validation set. Validation data should be split before transformation, then run through the same steps as training X.

Pipeline’s transform_input parameter (introduced in version 1.6) allows users to define metadata that should be transformed along with X until a step consumes it. LightGBM estimators are now compatible with this API. XGBoost does not support transform_input yet at the time of writing.

The new feature allows users to pass a validation set of their liking through a Pipeline, for instance by performing a train_test_split beforehand:

Figure 5: Passing X_val through a Pipeline with transform_input for early stopping.

Here X_val is transformed like X_train at every pipeline step until HistGradientBoostingClassifier.fit consumes it for early stopping.

Recent updates and ongoing work

Metadata routing is still experimental, but it is pretty mature in practice. On top of the pure routing, we continue developing features based on the metadata routing mechanism. Some are already implemented; others are still in progress:

Already available since 1.9:

• TargetEncoder can use grouped splitters (#33089)

In progress:

• Default requests, so users don’t need explicit set_*_request for common cases (#31413)
• Callbacks (e.g. ScoringMonitor) can accept metadata such as X_val and y_val (#34137)
• Developer API for customised metadata requests in consumers (#34314) (for further information see Developing estimators compliant with metadata routing)
• Visualization and debugging tools for metadata routing (#31535)

Once Metadata Routing gets released as a stable feature, the user’s code will look as simple as it always was for default cases, except we can now pass metadata and it will be used internally.

Takeaway

Metadata routing turns “please somehow get this array into the right nested fit/predict/score call” into a deliberate contract: pass values at the top and request them where they are consumed. This unlocks many new use cases and a tighter integration of scikit-learn compatible libraries in the ecosystem. The API is still experimental, but worth trying if your real data is grouped, weighted, or otherwise richer than (X, y).

Acknowledgements

I would like to thank Adrin Jalali, without whose consistent work on Metadata Routing, this feature wouldn’t exist.

Gael Varoquaux

Scikit-learn 1.9 release is out, and it comes with solid improvements to many existing estimators, making them faster, more stable, handling missing values, adding GPU support… The release also enhances the estimator displays in notebooks, and introduces a callback mechanism that opens the door to progress bars or advanced monitoring of convergence.

Improvement: Richer HTML views

The improvements that most will easily view are those on the estimator displays.
Since recent versions, the estimator views displayed in notebooks can show the parameters of the estimators (revealed by clicking on the estimator name). Latest release adds a view of the fitted attribute, as visible below:

In addition, the ColumnTransformer’s view has been enhanced to help the user understand how features are assembled:

A new promise: Callbacks

Scikit-learn 1.9 comes with a callback mechanism, currently experimental. We spent a lot of time designing it so that it enables many different uses: nested tracking of progress (even in parallel computing) on a variety of measures, early stopping…
The release notes come with an example on how to use these callbacks to monitor scores and to display progress bars – a more advance monitoring example.

As of today, the callbacks are implemented in logistic regression (with LBFGS solver), the various *SearchCV objects, Pipeline, StandardScaler. The next releases will progressively add callbacks in more and more estimators (this is a place where contributors can help).

Improved statistics and numerics

As users, what we like about scikit-learn routines is that they tend to be “fire-and-forget”, because they reliably run on a huge diversity of inputs: sparse inputs, missing values, different data types. This diversity of inputs is compounded by a diversity of modeling choices: different losses, sample weights…

Each release of scikit-learn extends the toolbox, sometimes by completing the combinatorial of options and data types rather than adding new estimators. Release 1.9 was a real consolidation in this respect:

Tree-based models

• Native missing-value support in RandomForestRegressor when minimizing the absolute error criterion

• Support of missing-values for tree-based models monotonic constraints

• Improved the statistical correctness of fitting with sample weights in HistGradientBoosting, RandomForest and ExtraTree (having exact support of sample weights in complex pipelines is challenging)

Linear models

• Logistic regression can use natively float32, thus removing memory pressure

• Multi-Task linear models support fitting on sparse X and sample weights

• More stable and faster RidgeCV and RidgeClassifierCV

• Gap safe screening of features for very fast fitting of sparse squared-loss regressors

Other models

• Sample weight support in minibatch kmeans (a very scalable clustering)

• Numeric stability of yeo-johnson in the preprocessing.PowerTransformer

• Faster Spectral embedding

Staying up to date with the ecosystem

Scikit-learn can now return sparse arrays, rather than sparse matrices. Indeed, scipy is slowly de-emphasizing sparse matrices, which often surprise users with their behavior that depart from arrays.

Increasing support for GPU

Scikit-learn is increasingly gaining support for optimized compute backends, which enables it, for instance, to run on GPUs. The challenge (and the value) is the incredible diversity of estimators and usecases supported by scikit-learn, and the package is progressively adding backend support in more and more places.
In the 1.9 release, the major features to gain GPU support were:

• Logistic regression and Poisson regression with LBFGS solver
• More metrics (eg average precision score, …)
• Nystroem kernel approximation

See the docs for all details on how to use the compute backends and which estimator support them.

PS: the user experience is currently not as good as with the default compute backend (numpy). But adding and improving GPU support (with the “array API”) is a good place for talented volunteers to help move the project forward.

Acknowledgements

Scikit-learn is the work of many contributors, with people volunteering their time as well as financial sponsors – see the funding page.

Lucy Liu

Note: this blog post is a cross-post of a Quansight Labs blog post.

The Consortium for Python Data API Standards developed the Python array API standard to define a consistent interface for array libraries, specifing core operations, data types, and behaviours. This enables ‘array-consuming’ libraries (such as scikit-learn) to write array-agnostic code that can be run on any array API compliant backend. Adopting array API support in scikit-learn means that users can pass arrays from any array API compliant library to functions that have been converted to be array-agnostic. This is useful because it allows users to take advantage of array library features, such as hardware acceleration, most notably via GPUs.

Indeed, GPU support in scikit-learn has been of interest for a long time - 11 years ago, we added an entry to our FAQ page explaining that we had no plans to add GPU support in the near future due to the software dependencies and platform specific issues it would introduce. By relying on the array API standard, however, these concerns can now be avoided.

In this blog post, I will provide an update to the array API adoption work in scikit-learn, since it’s initial introduction in version 1.3 two years ago. Thomas Fan’s blog post provides details on the status when array API support was initially added.

Current status

Since the introduction of array API support in version 1.3 of scikit-learn, several key developments have followed.

Vendoring array-api-compat and array-api-extra

Scikit-learn now vendors both array-api-compat and array-api-extra. array-api-compat is a wrapper around common array libraries (e.g., PyTorch, CuPy, JAX) that bridges gaps to ensure compatibility with the standard. It enables adoption of backwards incompatible changes while still allowing array libraries time to adopt the standard slowly. array-api-extra provides array functions not included in the standard but deemed useful for array-consuming libraries.

We chose to vendor these now much more mature libraries in order to avoid the complexity of conditionally handling optional dependencies throughout the codebase. This approach also follows precedent, as SciPy also vendors these packages.

Array libraries supported

Scikit-learn currently supports CuPy ndarrays, PyTorch tensors (testing against all devices: ‘cpu’, ‘cuda’, ‘mps’ and ‘xpu’) and NumPy arrays. JAX support is also on the horizon. The main focus of this work is addressing in-place mutations in the codebase. Follow PR #29647 for updates.

Beyond these libraries, scikit-learn also tests against array-api-strict, a reference implementation that strictly adheres to the array API specification. The purpose of array-api-strict is to help automate compliance checks for consuming libraries and to enable development and testing of array API functionality without the need for GPU or other specialized hardware. Array libraries that conform to the standard and pass the array-api-tests suite should be accepted by scikit-learn and SciPy, without any additional modifications from maintainers.

Estimators and metrics with array API support

The full list of metrics and estimators that now support array API can be found in our Array API support documentation page. The majority of high impact metrics have now been converted to be array API compatible. Many transformers are also now supported, notably LabelBinarizer which is widely used internally and simplifies other conversions.

Conversion of estimators is much more complicated as it often involves benchmarking different variations of code or consensus gathering on implementation choices. It generally requires many months of work by several maintainers. Nonetheless, support for LogisticRegression, GaussianNB, GaussianMixture, Ridge (and family: RidgeCV, RidgeClassifier, RidgeClassifierCV), Nystroem and PCA has been added. Work on GaussianProcessRegressor is also underway (follow at PR #33096).

Handling mixed array namespaces and devices

scikit-learn takes a unique approach among ‘array-consuming’ libraries by supporting mixed array namespace and device inputs. This design choice enables the framework to handle the practical complexities of end-to-end machine learning pipelines.

String-valued class labels are common in classification tasks and enable users to work with interpretable categories rather than integer codes. NumPy is currently the only array library with string array support, meaning that any workflow involving both GPU-accelerated computation and string labels necessarily involves mixed array type inputs.

Mixed array input support also enables flexible pipeline workflows. Pipelines provide significant value by chaining preprocessing steps and estimators into reusable workflows that prevent data leakage and ensure consistent preprocessing. However, they have an intentional design limitation: pipeline steps can transform feature arrays (X) but cannot modify target arrays (y). Allowing mixed array inputs means a pipeline can include a FunctionTransformer step that moves feature data from CPU to GPU to leverage hardware acceleration, while allowing the target array, which cannot be modified, to remain on CPU.

For example, mixed array inputs enable a pipeline where string classification features are encoded on CPU (as only NumPy supports string arrays), converted to torch CUDA tensors, then passed to the array API-compatible RidgeClassifier for GPU-accelerated computation:

from functools import partial

from sklearn.linear_model import RidgeClassifier
from sklearn.pipeline import make_pipeline
from sklearn.preprocessing import FunctionTransformer, TargetEncoder

pipeline = make_pipeline(
    # Encode string categories with average target values
    TargetEncoder(),
    # Convert feature array `X` to Torch CUDA device
    FunctionTransformer(partial(torch.asarray, dtype="float32", device="cuda"))
    RidgeClassifier(solver="svd"),
)

Work on adding mixed array type inputs for metrics and estimators is underway and expected to progress quickly. This work includes developing a robust testing framework, including for pipelines using mixed array types (follow PR #32755 for details).

Finally, we have also revived our work to support the ability to fit and predict on different namespaces/devices. This allows users to train models on GPU hardware but deploy predictions on CPU hardware, optimizing costs and accommodating different resource availability between training and production environments. Follow PR #33076 for details.

Challenges

The challenges of array API adoption remain largely unchanged from when this work began. These are also common to other array-consuming libraries, with a notable addition: the need to handle array movement between namespaces and devices to support mixed array type inputs.

Array API Standard is a subset of NumPy’s API

The array API standard only includes widely-used functions implemented across most array libraries, meaning many NumPy functions are absent. When such a function is encountered while adding array API support, we have the following options:

• add the function to array-api-extra - this allows other array-consuming libraries to benefit and allows sharing of maintenance burden, but is only relevant for more widely used functions
• add our own implementation in scikit-learn - these functions live in sklearn/utils/_array_api.py
• check if SciPy implements an array API compatible version of the function

The quantile function illustrates this decision-making process. quantile is not included in the standard as it is not widely used (outside of scikit-learn) and while it is implemented in most array libraries, the set of quantile methods supported and their APIs vary. Currently, scikit-learn maintains its own array API compatible version that supports both weights and NaNs, but due to the maintenance burden we decided to investigate alternatives. SciPy has an array API compatible implementation, but it did not support weights. We thus investigated adding quantile to array-api-extra; however, during this effort, SciPy decided to add weight support. Thus, we ultimately decided to transition to the SciPy implementation once our minimum SciPy version allows.

Compiled code

Many performance-critical parts of scikit-learn are written using compiled code extensions in Cython, C or C++. These directly access the underlying memory buffers of NumPy arrays and are thus restricted to CPU.

Metrics and estimators, with compiled code, handle this in one of two ways: convert arrays to NumPy first or maintain two parallel branches of code, one for NumPy (compiled) and one for other array types (array API compatible). When performance is less critical or array API conversion provides no gains (e.g., confusion_matrix), we convert to NumPy. When performance gains are significant, we accept the maintenance burden of dual code paths. This was the case for LogisticRegression and the extensive process required for making such implementation decisions can be seen in the PR #32644.

Unspecified behaviour in the standard

The array API standard intentionally leaves some function behaviors unspecified, permitting implementation differences across array libraries. For example, the order of unique elements is not specified for the unique_* functions and as of NumPy version 2.3, some unique_* functions no longer return sorted values. This will require code amendments in cases where sorted output was relied upon.

Similarly, NaN handing is also unspecified for sort; however, in this case, all array libraries currently supported by scikit-learn follow NumPy’s NaN semantics, placing NaNs at the end. This consistency eliminates the need for special handling code, though comprehensive testing remains essential when adding support for new array libraries.

Device transfer

Mixed array namespace and device inputs necessitates conversion of arrays between different namespaces and devices. This presented a number of considerations and challenges.

The array API standard adopted DLPack as the recommended data interchange protocol. This protocol is widely implemented in array libraries and offers an efficient, C ABI compatible protocol for array conversion. While this provided us with an easy way to implement these transfers, there were limitations. Cross-device transfer capability was only introduced in DLPack v1, released in September 2024. This meant that only the latest PyTorch and CuPy versions have support for DLPack v1. Moreover, not all array libraries have adopted support yet. We therefore implemented a ‘manual’ fallback; however, this requires conversion via NumPy when the transfer involves two non-NumPy arrays. Additionally, there are no DLPack tests in array-api-tests, a testing suite to verify standard compliance, leaving DLPack implementation bugs easier to overlook. Despite these challenges, scikit-learn will benefit from future improvements, such as addition of a C-level API for DLPack exchange that bypasses Python function calls, offering significant benefit for GPU applications.

Beyond the technical considerations, there were also user interface considerations. How should we inform users that these conversions, which incur memory and performance cost, are occurring? We decided against warnings, which risk being ignored or becoming a nuisance, and to instead clearly document this behaviour. Additionally, different devices have different data type limitations; for example, Apple MPS only supports float32. How best to handle these differences when performing conversions while ensuring users are informed of precision impacts is an ongoing consideration.

A quick benchmark

Array API support for Ridge regression was added in version 1.5, enabling GPU-accelerated linear models in scikit-learn. Combined with support of several transformers, this allows for complete preprocessing and estimation pipelines on GPU.

The following benchmark shows the use of the MaxAbsScaler transformed followed by Ridge regression using randomly generated data with 500,000 samples and 300 features. The benchmarks were run on AMD Ryzen Threadripper 2970WX CPU, NVIDIA Quadro RTX 8000 GPU and Apple M4 GPU (Metal 3).

The figure below shows the performance speed up on CuPy, Torch CPU and Torch GPU relative to NumPy.

Performance speedup relative to NumPy across different backends.

The observed speedups are representative of performance gains achievable with sufficiently large datasets on datacenter-grade GPUs for linear algebra-intensive workloads. Mobile GPUs, such as those in laptops, would typically yield more modest improvements.

Note that scikit-learn’s Ridge regressor currently only supports ‘svd’ solver. We selected this solver for initial implementation as it exclusively uses standard-compliant functions available across all backends and is the most stable solver. Support for the ‘cholesky’ solver is also underway (see details in PR #29318).

Looking forward

As of version 1.8, array API support is still in experimental mode and thus not enabled by default. However, we welcome early adopters and interested users to try it and report any issues. See our documentation for details on enabling array API support.

Before removing experimental status, we would like to:

• develop a system for automatically documenting functions and classes that support array API, potentially with the ability to add relevant details
• mixed array type input support
• support fit and predict on different hardware by allowing conversion of fitted estimators between namespaces/devices using utility functions
• improved testing, in particular for the new mixed array type functionalities
• improved documentation, including adding an example to our gallery
• decide on the minimal dependency versions required
• get real world user feedback

Alongside these infrastructure and framework improvements, we look forward to adding support for more estimators. These improvements will deliver production-ready GPU support and flexible deployment options to scikit-learn users. We welcome community involvement through testing and feedback throughout this development phase.

Acknowledgements

Work on array API in scikit-learn has been a combined effort from many contributors. This work was partly funded by CZI and NASA Roses.

I would like to thank Olivier Grisel, Tim Head and Evgeni Burovski for helping me with my array API questions.

Dea María Léon

User experience (UX) has always been an important focus for scikit-learn. As we know, UX encompasses many aspects, but here we will focus specifically on how easy it is for the user to understand scikit-learn models during development, especially while using tools like jupyter notebooks.

First visualizations

Initial work to allow users to inspect their models interactively began in 2019, when Thomas J. Fan introduced HTML visualizations for estimators. He continued to build on this foundation with additional improvements in subsequent contributions.

Lack of resources to go forward

In June 2023, issue 26595 was opened by Gaël Varoquaux outlining several potential enhancements to the HTML displays. These ideas stemmed from direct interactions with users, which clearly highlighted the need for further work in this area. Unfortunately, due to a lack of resources, the issue remained open for approximately a year and a half.

Wellcome grant awarded to scikit-learn

This was until the end of 2023, when Guillaume Lemaitre applied for a grant with the help of NumFOCUS, that the broader topic of Predictive model evaluation and inspection was formalized. Enhancing user experience through interactive inspection is an essential part of this effort and falls within the scope of the grant.

The grant was awarded to scikit-learnand it is from the Chan Zuckerberg Initiative (CZI) through its Essential Open-Source Software for Science (EOSS) program. It is funded by The Wellcome Trust and administered by NumFOCUS. Thanks to this financial support, work is well underway. And several objectives from the said issue have already been completed. See the grant application here.

First milestone: Added interactive parameters table for each element

The first milestone was introduced inscikit-learn version 1.7, released in June 2025. A parameters table was added to the HTML representation of models, displaying parameter names and their corresponding values. Non-default parameters—those explicitly set by the user—are highlighted. In addition, a copy-to-clipboard button is available for each parameter name. The parameter name that is copied to the clipboard is the fully classified name, which is shown on hover as well. The parameters table is collapsed by default and can be opened by the user.

The following two images show a pipeline table before and after the milestone.

Second milestone: Links to parameters documentation and tooltip preview

This feature was further enhanced in version 1.8, released in December 2025. We added tooltips that provide documentation for each parameter, as well as links to the online documentation. See the GIF below or this example for more details: Displaying estimators and complex pipelines.

Planned improvements

More features are now being implemented. In particular, users will be able to visualize feature names and values, display fitted attributes and further improve the overall appearance of the interactive displays.

Reshama Shaikh

Virgil Chan

BIO: Virgil Chan is currently a Forward Deployed Engineer - Pre-Sales at Union.ai. Before that, he worked as a consultant in the San Francisco Bay Area, specialising in predictive data analytics and machine learning. Earlier, he studied mathematics before moving into data science. Virgil joined the scikit-learn team as a Contributor Experience Team member in December 2024.

• GitHub: @virchan
• LinkedIn: @virgil-chan
• Website: https://virchan.github.io

1. Tell us about yourself.

   My name is Virgil, and I’m currently working as a Forward Deployed Engineer – Pre-Sales at Union.ai. Based in San Jose, California, I previously worked as a consultant, using libraries from the scientific Python ecosystem on data science and machine-learning projects, including medical data analysis, traffic-network prediction, and model evaluation. Before deciding that computers are more fun, I was doing mathematical research in topology.

2. How did you first get involved in open source?

   I first got involved in open source during the COVID-19 lockdown. I used that time to study Python programming, data science, analytics, and machine learning, and that’s when I discovered libraries like NumPy, Pandas, scikit-learn, NetworkX, and TensorFlow. Once I became more confident in my skills, I started working as a consultant and used these libraries to deliver data-driven solutions for clients.

3. We would love to learn of your open source journey.

   I was transitioning from academia into software development, and I quickly learnt that companies valued hands-on experience more than an advanced degree. At the same time, the rise of GPU-driven workloads and LLM-based solutions made my earlier consulting projects look less impressive on paper. I ended up stuck in the infinite loop of no-job-no-experience.

   Even though I came from a non-traditional background, and my resume didn’t match what recruiters and ATS systems usually look for, I’ve always believed that my experience is something I can build myself. Since companies weren’t keen on training junior developers, open source became one of the not-so-many viable paths. I started looking for a project where I could grow, be useful, and apply my academic training in a meaningful way. That search naturally led me to scikit-learn.

4. How did you get involved in scikit-learn?

   My first PR to scikit-learn (scikit-learn/scikit-learn#27913) was a classic “good first issue”: adding the URL of a scikit-learn example to the relevant places in the documentation. I opened it in December 2023 and it was merged into the main branch in March 2024. Maren helped me navigate the codebase and understand the CI workflow, which gave me a solid foundation for later contributions. Even though I’m now more experienced with the contributing workflow, I still revisit that PR from time to time to remind myself of the challenges first-time contributors face, and how I can support them.

   My next PR (scikit-learn/scikit-learn#29709) was more technical, fixing a bug in the (root) mean squared log error function. The expected behaviour was to check that inputs were in the domain of $\log(1 + x)$, but the implementation at the time checked the domain of $\log(x)$ instead. It was one of the few issues I fully understood and knew how to solve, so I volunteered to create a PR. Adrin reviewed it and mentored me throughout the process. Once everything looked good and the CI passed, he asked me to add array API support to the function. And that’s where the fun began.

   I had no idea what the array API was, but I already had the habit of reading discussions and merged PRs in my spare time. With a bit of Googling, I quickly understood what needed to be done and the broader importance of the array API project. In fact, completing the array API project has become one of my mid-term goals for my scikit-learn work. Under the guidance of Adrin, Guillaume, Olivier, and Omar, my PRs improved, and contributing became even more rewarding because of how supportive the maintainers were. I also started reviewing PRs, especially from first-time contributors working on the same “good first issue” I began with. In December 2024, I joined the scikit-learn team.

   I’m honoured that the team welcomed me and trusted me with more responsibility, such as representing scikit-learn at the Scientific Python Developer Summit in May 2025, implementing temperature scaling as a new feature (with Christian), and having the ability to run CUDA CI myself. It feels good to pass the same positivity I received back into the community.

5. To which OSS projects and communities do you contribute?

   I’m also interested in scaling machine-learning algorithms, so I’ve been exploring CUDA and cuML as well.

6. What is alluring about OSS?

   Open source fosters a collaborative environment where everyone wins: end-users, maintainers, and contributors. Because it is volunteer-driven, it becomes easier to recognise that the problem itself is the problem, the bug or the issue, rather than the people involved. As a result, the usual institutional complications, such as power or ego struggles, conflicts of interest over funding, or pressure from deadlines, are far less likely to drag the project down. People have more freedom to focus on solving problems, which creates an ideal environment for exploration, experimentation, collaboration, learning, and growth.

   Open source has given me the chance to grow, develop new skills, and broaden my perspective, something I’ve been battling since finishing college. By trading my time for responsibility, I’ve found open source to be a meaningful and genuinely rewarding experience.

7. What are your favorite resources, books, courses, conferences, etc?

   I found the interview between scikit-learn and Code for Thought on YouTube. The maintainers shared their open-source journeys from how they got started to how they became involved in scikit-learn, which I found inspiring and motivating. For example, I can’t agree more with Gael’s point that “open source should be spontaneous” and that “a diversity of opinion will make better software.” I also learned from Adrin that I could get more involved in the project by becoming the second reviewer for a PR, which gave me the confidence to start reviewing PRs. I think this interview can help people understand the project from a more human and non-technical perspective.

8. What are your hobbies, outside of work and open source?

   If I’m done with work and house chores, I usually listen to music. I enjoy classical music (Mozart, Brahms, Rachmaninoff, etc.), and I’m currently getting more exposure to Chopin’s work. I also like Rock ‘n’ Roll (Led Zeppelin, Eric Clapton, Deep Purple, etc.), and I find that AC/DC can “push me to eleven” whenever I’m stuck at work.

   I also enjoy reading novels. At the moment I’m reading The Silmarillion by Tolkien, and my to-read list keeps growing.

   I like hanging out with cats as well. I volunteer with an animal rescue group in San Jose, where I help care for the cats in their sanctuary and assist at adoption fairs.

Reshama Shaikh

Summary

scikit-learn was honored to be selected to participate in Cohort 2 of the GitHub Secure Open Source Fund (OSF) Training Program. Cohort 1 took place earlier in 2025 with 19 projects, and Cohort 2 took place with 52 projects during June 2025.

It was an intense 3-week training program, with over 90 open source maintainers joining the training. Read the announcement from GitHub: Securing the supply chain at scale: Starting with 71 important open source projects

There were numerous workshops delivered by experts in the GitHub Security Lab. For many of these workshops, the learning materials are publicly available, and they are shared below.

GitHub Security Lab

GitHub has its own security department, and GitHub Security Lab’s mission is to empower developers and secure open source.

• GitHub Security Lab: Resources

Resources for Security Training

The training provided many trainings by experts in the field. Below we share trainings that are available to the public.

• Configuring private vulnerability reporting for a repository

  Owners and administrators of public repositories can allow security researchers to report vulnerabilities securely in the repository by enabling private vulnerability reporting.

• OpenSSF Scorecard
• Secure by design: A UX toolkit

CodeQL: From Zero to Hero

This workshop introduces fundamentals of security research and static analysis used when looking for vulnerabilities in software. They use an example of a simple vulnerability, walk through how CodeQL could detect it, and provide examples on how the audience could use CodeQL to find vulnerabilities themselves.

slides: Finding Vulnerabilities with CodeQL

Developing Secure Software

This course includes specific tips on how to use and develop open source and other software securely. Learn the security basics to develop software that is hardened against attacks, and understand how you can reduce the damage and speed the response when a vulnerability is exploited.

It was developed by the Open Source Security Foundation (OpenSSF), a cross-industry collaboration that brings together leaders to improve the security of open source software by building a broader community, targeted initiatives, and best practices.

• Online, Self Paced
• 16-20 Hours of Course Material
• Quizzes and Hands-on Labs

OSS-Fuzz

Fuzz testing is a well-known technique for uncovering programming errors in software.

Secure Code Game

Secure Code Game is a GitHub Security Lab initiative, providing an in-repo learning experience, where learners to secure intentionally vulnerable code. At the same time, this is an open source project that welcomes your contributions as a way to give back to the community.

Participate in Future Cohorts of the GitHub Secure Open Source Training

If you are a maintainer of an open source project, this training is an excellent opportunity to secure your project with guidance from highly trained experts in the security field. Applications are open.

References

• Securing the supply chain at scale: Starting with 71 important open source projects (11-Aug-2025)
• TechCrunch: GitHub launches $1.25M open source fund with a focus on security (19-Nov-2024)
• GitHub Secure Open Source Fund
• Eclipse Foundation Security Policy
• Linux Foundation Security Policy

Blogs from Participating Open Source Projects

• OpenCV: OpenCV’s Participation in the GitHub Secure Open Source Fund
• Bootstrap: Bootstrap at GitHub Secure Open Source Fund
• Cobra & Viper: Cobra & Viper Fortify Security as Part of GitHub Secure Open Source Fund
• Zitadel: A Leap Forward in Security: Our Journey with the GitHub Secure Open Source Fund

Acknowledgments

Thank you to the funders and ecosystem partners of the GitHub Secure Open Source Fund.

Funding Partners: Alfred P. Sloan Foundation, American Express, Chainguard, Datadog, Herodevs, Kraken, Mayfield, Microsoft, Shopify, Stripe, Superbloom, Vercel, Zerodha, 1Password

Ecosystem Partners: Ecosyste.ms, CURIOSS, Digital Data Design Institute Lab for Innovation Science, Digital Infrastructure Insights Fund, Microsoft for Startups, Mozilla, OpenForum Europe, Open Source Collective, OpenUK, Open Technology Fund, OpenSSF, Open Source Initiative, OpenJS Foundation, University of California, Santa Cruz OSPO, Sovereign Tech Agency, SustainOSS

Skolar

Pénélope Gittos

This blog post has been submitted by Probabl, a sponsor of scikit-learn. The scikit-learn project values educational efforts that build and nurture a strong vibrant open-source community. The goal of this is straightforward: give everyone, everywhere, the tools they need to easily grasp, engage with, and meaningfully contribute to data science using open-source software. This mission is shared and actively supported by Probabl, a company that helps maintain scikit-learn by employing many of its core contributors and investing in its long-term sustainability. With Probabl’s support and a deep commitment from the community, the scikit-learn ecosystem continues building bridges between research, software, and education.

When the Inria scikit-learn MOOC (Massive Open Online Course) first went live, the community got a front-row seat to the amazing impact of practical, accessible and open learning. Created by several core developers and maintainers of scikit-learn—now working at Probabl—the MOOC has reached over 40,000 learners worldwide, clearly highlighting the demand for organized, hands-on resources that blend theory with real-world practice.

Today, Probabl is excited to introduce Skolar, a new, fully open-source educational initiative, built directly from your feedback and all the lessons we’ve learned along the way. Developed and extended by those same core developers of scikit-learn, Skolar is designed specifically for data science practitioners, offering hands-on, high-quality learning resources grounded in real-world applications and open-source values.

Skolar exists to boost our shared values: openness, teamwork, and practicality. It offers clear, interactive tutorials and structured courses carefully designed to match industry challenges and specialized use-cases. But even more importantly, it captures the true spirit of open source: encouraging collaboration, peer-to-peer learning, and guidance from experts.

Right now, we’re just at the beginning. Today, you can dive into our Scikit-learn Associate Practitioner online course, adapted from the popular Inria MOOC but enhanced with new material on unsupervised learning, especially clustering.

The next stages, professional and expert levels, will be released soon. We’ll also add more courses covering other open-source libraries such as skrub (for data wrangling), hazardous (for survival analysis), and fairlearn (for fairness). Additionally, our scikit-learn team is planning to create industry-specific modules tackling real-world needs in fields like healthcare, finance, medicine, and beyond.

At its core, Skolar is about empowering people through education, driven entirely by our passion for openness and collaboration. We firmly believe that true open data science begins with community-built learning resources. We warmly welcome you, whether you’re a contributor, learner, teacher, or just someone curious, to join us. Help shape Skolar’s future and support open-source education in data science.

Create your account on Skolar today: https://skolar.probabl.ai

Contribute to the scikit-learn course contents, or contribute to the learning platform’s backend or frontend.

Adrin Jalali

Historically, scikit-learn’s API has been divided into public and private. Public API is intended to be used by users, and private API is used internally in scikit-learn to develop new features and estimators. However, many of those functionalities have become essential to develop scikit-learn estimators by third parties who develop them outside the scikit-learn codebase.

When it comes to our public API, we have very strict and high standards on backward compatibility. The rule of thumb is that no change should cause a change in users’ code unless we warn about it for two release cycles, which means we give users a year time to update their code.

On the other hand, we have no such guarantees or constraints on our private API. This brings an issue to third party developers who would like to use methods used by scikit-learn developers to develop their estimators. Constantly changing private API without prior warning brings certain challenges to third party developers which is not ideal.

As a result, we’ve been working on creating a developer API which would sit somewhere between our public and private API in terms of backward compatibility. That means we intend to try to keep that API stable, and if needed, introduce changes with one release cycle warning.

In the past few releases, we’ve slowly introduced more functionalities under this umbrella. __sklearn_clone__ and __sklearn_is_fitted__ are two examples.

In the 1.6 release, we focused on the testing infrastructure and estimator tag system. Estimator tags used to be private, and we were not sure about their design. In the 1.6 release, new tags are introduced and using them looks like the following:

from sklearn.base import BaseEstimator, ClassifierMixin

class MyEstimator(ClassifierMixin, BaseEstimator):

  ...

  def __sklearn_tags__(self):
    tags = super().__sklearn_tags__()
    # modify tags here
    tags.non_deterministic = True
    return tags

The new tags mostly follow the same structure as the old tags, but there are certain changes to them. The main change is that the old _xfail_checks is no longer present in the new tags. That tag was used to tell the common testing tools about the tests which are known to fail and are to be skipped. That information is now directly passed to the test functionalities. The old way of skipping a test was the following:

from sklearn.base import BaseEstimator, ClassifierMixin

class MyEstimator(ClassifierMixin, BaseEstimator):

  ...

  def _more_tags(self):
    return {
      "_xfail_checks": {
        "check_to_skip_name": "this check is known to fail",
        ...
      }
    }

And then when calling check_estimator or using parametrize_with_checks with pytest would automatically ignore those tests for the estimator.

Instead, in this release, you pass that information directly to those methods:

from sklearn.utils.estimator_checks import check_estimator, parametrize_with_checks

CHECKS_EXPECTED_TO_FAIL = {
  "check_to_skip_name": "this check is known to fail",
  ...
}

# Using check_estimator
def test_with_check_estimator():
  check_estimator(MyEstimator(), expected_failed_checks=CHECKS_EXPECTED_TO_FAIL)

# Using parametrize_with_checks
@parametrize_with_checks(
  [MyEstimator()],
  expected_failed_checks=lambda est: CHECKS_EXPECTED_TO_FAIL
)
def test_with_parametrize_with_checks(estimator, check):
  check(estimator)

While working on the testing infrastructure, we have also been working on improving our tests and that means in this release we had a particularly high number of changes in their names and what they do. The changes will make it easier for developers to fix issues with their estimators. Note that you can now pass legacy=False to both check_estimator and parametrize_with_checks to include only strictly API related tests.

The above changes mean developers need to update their estimators and depending on what they use, write scikit-learn version specific code to handle supporting multiple scikit-learn versions. To make that process easier, we’ve worked on a package called sklearn_compat. You can either depend on it as a package dependency, or vendor a single file inside your project. At the moment this project is in its infancy and might change in the future. But hopefully it helps developers out there.

If you think there are missing functionalities in the developer API, please let us know and give us feedback on our issue tracker.

Inessa Pawson

François Goupil

We are excited to announce the launch of the scikit-learn user survey! Scikit-learn continues to evolve thanks to contributions from its diverse user community. As we plan for future releases, we want to ensure we are focusing on what matters most to you — our users.

The goal of this survey is to better understand how users interact with the library, identify any pain points, learn about the features you find most useful, and what’s missing. This is your chance to have a say in how the library grows and adapts to meet the evolving needs of the machine learning community.

The survey will take about 15 minutes of your time. It is available in Arabic, French, English, Japanese, Mandarin, Spanish, and Portuguese. You have the option to remain completely anonymous, and the data collected will be used solely for the purpose of improving scikit-learn.

This user survey is a truly collaborative effort. We would like to thank the teams from probabl, University of Oxford (UK), and POSSEE OpenTeams, as well as many scikit-learn contributors, for their time and effort in designing and translating it.

Once the survey closes, we’ll analyze the responses and publish the findings in a follow-up blog post.

To take the survey, visit: https://forms.gle/p5P7AweCJCbFMzfo6. The survey will remain open until October 14th, 2024, and we encourage you to share it with your colleagues and extended network.

We value every contribution in our community, and we’re committed to making scikit-learn even better. Your feedback is the foundation upon which scikit-learn will continue to grow and evolve. We look forward to hearing from you!