chore(skore): Using pixi to manage the lock files and CI by glemaitre · Pull Request #2929 · probabl-ai/skore

glemaitre · 2026-05-21T12:28:56Z

closes #1659
closes #2809

Now that we are in monorepo, I would rather use a tool like pixi to orchestrate task and the CI jobs and update the lock file.

This PR is going towards this direction.

However, it does not force any user to absolutely use pixi as a development tools (the same way that it was not necessary before hand to use uv for instance).

What this CI proposes:

create a cross-platform lock file
use the lock file for the documentation and code testing
add a codecov integration instead of add the report in a message.

github-actions · 2026-05-21T12:35:11Z

Documentation preview @ 0c7f303

github-actions · 2026-05-21T12:44:12Z

Tests	Skipped	Failures	Errors	Time
2564	6 💤	0 ❌	0 🔥	6m 37s ⏱️

auguste-probabl · 2026-05-21T13:19:20Z

Yes, please!

auguste-probabl · 2026-05-26T08:44:10Z

Is there something specific keeping this in draft @glemaitre ? I'm very excited to have a coherent, reproducible dev environment.

rouk1

IMHO this needs to be documented in contribution guidelines.
How to install pixi and dot and how to spawn a virtualenv.

glemaitre · 2026-06-08T14:09:19Z

IMHO this needs to be documented in contribution guidelines.

We can indeed document the way of using pixi if one is interested in.

thomass-dev · 2026-06-08T14:37:50Z

IMHO this needs to be documented in contribution guidelines.

We can indeed document the way of using pixi if one is interested in.

It's not only "if one is interested in".

The lockfiles used in the CI are now only in pixi "language".
If someone wants to debug and reproduce the environment, they cannot use a simple requirements file anymore.
He has to use pixi, where requirements.txt was more "cross-package-manager".

glemaitre · 2026-06-08T15:00:11Z

If someone wants to debug and reproduce the environment, they cannot use a simple requirements file anymore.

OK I see. I was not considering this use case.

thomass-dev · 2026-06-08T15:25:36Z

Also, "how to update lockfiles" should be documented, both when adding a new dependency or when dependencies have to be upgraded.

In a way, this PR forces maintainers to adopt pixi.

thomass-dev · 2026-06-08T15:26:41Z

+# Python deps are now resolved by pixi (see `pixi.toml` / `pixi.lock`).
+# Dependabot has no native pixi ecosystem; refresh the lockfile with `pixi update`
+# (manually or via a scheduled workflow).


This is really not cool :(.

We can create a bot as we do in skrub that open a PR weekly.

e.g. https://github.com/skrub-data/skrub/blob/main/.github/workflows/update_pixi_lock_files.yml

yes, we should

Maintaining our own dependabot 😅 .

we are maintaining a whole in-house dependency tracking system right now, so I think it is a net improvement tbh

whole in-house dependency tracking system

That's not true, and it's really unfair. 😉

Before, we used:

pyproject.toml to define dependencies,

a txt file to override dependencies (matrix),

a bash script to read the txt file and generate requirements.txt files using uv.

With this PR, you need:

pyproject.toml to define dependencies,

a pixi.toml to define dependencies,

a pixi command to read the pixi.toml file and generate the pixi.lock.

Also, the txt file was used in the CI, so with one file we were able to generate lockfiles and to control matrix in the CI. With this PR, we have to redefine matrix both in the CI and in the pixi.toml.

The underlying system is the same, in a different language pixi vs bash+uv: defining lockfiles.

The only advantage is the invisible venv management in the CI + the automatic lockfiles check.
This latest advantage is mitigated by the fact that a replacement for dependabot needs to be created.
Otherwise, the complexity in the CI is strictly the same, and i'm still not convinced.

whole in-house dependency tracking system

That's not true, and it's really unfair. 😉

pip-compile.sh and supported-versions.json are an attempt at a home-grown dependency tracking system, and it works fine, don't get me wrong!

But it's less powerful (e.g granularity of lock files), less standard, and less well-documented than a bespoke tool like pixi or uv

glemaitre · 2026-06-08T15:56:09Z

It's not only "if one is interested in".

The lockfiles used in the CI are now only in pixi "language".
If someone wants to debug and reproduce the environment, they cannot use a simple requirements file anymore.
He has to use pixi, where requirements.txt was more "cross-package-manager".

I added a pixi task that could help at exporting a pure requirements.txt file. Maybe we can revisit when pylock.toml is supported.

rouk1

🤣

Side note: cursor/vscode never succeed in auto enabling the correct pixi venv.

jeromedockes · 2026-06-09T07:59:56Z

FWIW the pixi workflow proposed by @glemaitre is more or less what he set up for skrub like 1.5 year ago and it has worked well for skrub. personally I don't use pixi for my day-to-day work, only when there is an error in one of the CI jobs that I don't reproduce in my local env I will run pixi run -e ci-env-name pytest test_.py::test_it. the pixi run -e <env> part I copy-paste from the ci log. so I would say I use pixi less than monthly. Usually when I do it is for the env using the nightly builds of scientific packages which are not on PyPI or conda-forge but on other indexes so just doing pixi run -e ci-nightly-deps is convenient (I'm sure there are other ways besides pixi to have that convenience)

thomass-dev · 2026-06-09T08:06:52Z

This message is meant to be factual, and i'm looking for arguments in favor of pixi (i hope this isn't taken as passive-aggressive).

FWIW the pixi workflow proposed by @glemaitre is more or less what he set up for skrub like 1.5 year ago and it has worked well for skrub. personally I don't use pixi for my day-to-day work, only when there is an error in one of the CI jobs that I don't reproduce in my local env I will run pixi run -e ci-env-name pytest test_.py::test_it. the pixi run -e <env> part I copy-paste from the ci log. so I would say I use pixi less than monthly. Usually when I do it is for the env using the nightly builds of scientific packages which are not on PyPI or conda-forge but on other indexes so just doing pixi run -e ci-nightly-deps is convenient (I'm sure there are other ways besides pixi to have that convenience)

So what is the benefit of changing the CI from uv+bash+gh to pixi+gh? The argument of "bash" doesn't convince me, pixi is another language to learn, and the diff +30K -5K neither. The same goes for reproducibility; that's what lockfiles are for, whether you're using pixi or not.

I'm not convinced.

(by the way, i'm starting my review)

jeromedockes · 2026-06-09T12:08:58Z

and i'm looking for arguments in favor of pixi

I wasn't arguing for or against pixi, just saying what was my experience with this setup in another project. I don't have an opinion either way.

(i hope this isn't taken as passive-aggressive).

don't worry :) it did not come across like that

thomass-dev · 2026-06-09T15:16:16Z

This message is meant to be factual, and i'm looking for arguments in favor of pixi (i hope this isn't taken as passive-aggressive).

FWIW the pixi workflow proposed by @glemaitre is more or less what he set up for skrub like 1.5 year ago and it has worked well for skrub. personally I don't use pixi for my day-to-day work, only when there is an error in one of the CI jobs that I don't reproduce in my local env I will run pixi run -e ci-env-name pytest test_.py::test_it. the pixi run -e <env> part I copy-paste from the ci log. so I would say I use pixi less than monthly. Usually when I do it is for the env using the nightly builds of scientific packages which are not on PyPI or conda-forge but on other indexes so just doing pixi run -e ci-nightly-deps is convenient (I'm sure there are other ways besides pixi to have that convenience)

So what is the benefit of changing the CI from uv+bash+gh to pixi+gh? The argument of "bash" doesn't convince me, pixi is another language to learn, and the diff +30K -5K neither. The same goes for reproducibility; that's what lockfiles are for, whether you're using pixi or not.

I'm not convinced.

(by the way, i'm starting my review)

Sorry @jeromedockes , in fact my message was implicitly addressed to @glemaitre .

# Conflicts: # .github/workflows/lint.yml # .github/workflows/pr-display-code-coverage.yml # .github/workflows/pytest.yml # .github/workflows/sphinx.yml # ci/requirements/skore/python-3.11/scikit-learn-1.6/test-requirements.txt # ci/requirements/skore/python-3.11/scikit-learn-1.6_and_mlflow-2/test-requirements.txt # ci/requirements/skore/python-3.11/scikit-learn-1.9/test-requirements.txt # ci/requirements/skore/python-3.12/scikit-learn-1.6/test-requirements.txt # ci/requirements/skore/python-3.12/scikit-learn-1.9/test-requirements.txt # ci/requirements/skore/python-3.13/scikit-learn-1.6/test-requirements.txt # ci/requirements/skore/python-3.13/scikit-learn-1.9/test-requirements.txt # ci/requirements/skore/python-3.14/scikit-learn-1.7/test-requirements.txt # ci/requirements/skore/python-3.14/scikit-learn-1.8/test-requirements.txt # ci/requirements/skore/python-3.14/scikit-learn-1.9/sphinx-requirements.txt # ci/requirements/skore/python-3.14/scikit-learn-1.9/test-requirements.txt # ci/requirements/skore/python-3.14/scikit-learn-1.9_and_mlflow-3/test-requirements.txt # ci/requirements/skore/python-3.14/scikit-learn-1.9_and_pandas-2/test-requirements.txt # docs/how-to/bump-minimal-python-version.md

glemaitre · 2026-06-20T12:29:32Z

Side note: cursor/vscode never succeed in auto enabling the correct pixi venv.

It is weird, it works normally with the Python extension out of the box.

chore(skore): Using pixi to manage the lock files and CI

eaefe45

glemaitre requested review from auguste-probabl, rouk1 and thomass-dev as code owners May 21, 2026 12:28

glemaitre marked this pull request as draft May 21, 2026 12:39

add codecov

6cac458

glemaitre added 2 commits May 21, 2026 15:25

fix

1539dc8

fix token

0f47346

probabl-ai deleted a comment from codecov Bot May 21, 2026

glemaitre added 2 commits May 21, 2026 19:06

fix coverage (maybe)

cd65c9a

really fix coverage this time

6866200

auguste-probabl reviewed May 22, 2026

View reviewed changes

Comment thread scripts/activate_dot.sh

auguste-probabl reviewed May 25, 2026

View reviewed changes

Comment thread scripts/activate_dot.sh

glemaitre added 2 commits May 25, 2026 19:08

add scripts/ folder

fc39150

Merge branch 'main' into pixi_setup

1d219ca

auguste-probabl reviewed May 26, 2026

View reviewed changes

Comment thread pixi.toml

auguste-probabl mentioned this pull request May 26, 2026

ci: Upload coverage to codecov #2354

Closed

glemaitre added 2 commits June 4, 2026 16:04

Merge remote-tracking branch 'origin/main' into pixi_setup

8880403

Merge remote-tracking branch 'glemaitre/pixi_setup' into pixi_setup

1a6645d

auguste-probabl reviewed Jun 4, 2026

View reviewed changes

Comment thread pixi.toml Outdated

glemaitre added 2 commits June 4, 2026 23:08

_

5551fce

_

7783efc

glemaitre marked this pull request as ready for review June 5, 2026 13:25

auguste-probabl reviewed Jun 8, 2026

View reviewed changes

Comment thread docs/how-to/bump-minimal-python-version.md

rouk1 reviewed Jun 8, 2026

View reviewed changes

Comment thread .github/workflows/pr-display-code-coverage.yml Outdated

thomass-dev reviewed Jun 8, 2026

View reviewed changes

Comment thread .github/workflows/pytest.yml

_

1156c27

glemaitre commented Jun 8, 2026

View reviewed changes

Comment thread CONTRIBUTING.rst

rouk1 reviewed Jun 9, 2026

View reviewed changes

Comment thread CONTRIBUTING.rst

Comment thread .github/workflows/sphinx.yml Outdated

Comment thread .github/workflows/sphinx.yml Outdated

thomass-dev reviewed Jun 9, 2026

View reviewed changes

Comment thread .github/workflows/sphinx.yml

thomass-dev reviewed Jun 9, 2026

View reviewed changes

Comment thread .github/workflows/sphinx.yml

auguste-probabl reviewed Jun 9, 2026

View reviewed changes

Comment thread CONTRIBUTING.rst Outdated

auguste-probabl reviewed Jun 9, 2026

View reviewed changes

Comment thread CONTRIBUTING.rst Outdated

thomass-dev requested changes Jun 9, 2026

View reviewed changes

Comment thread .github/workflows/pytest.yml

glemaitre added 3 commits June 20, 2026 11:14

address reviews

bb1765a

fix lint env

0c7f303

Conversation

glemaitre commented May 21, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

github-actions Bot commented May 21, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

github-actions Bot commented May 21, 2026

Uh oh!

auguste-probabl commented May 21, 2026

Uh oh!

Uh oh!

Uh oh!

Uh oh!

auguste-probabl commented May 26, 2026

Uh oh!

Uh oh!

Uh oh!

rouk1 left a comment

Choose a reason for hiding this comment

Uh oh!

Uh oh!

glemaitre commented Jun 8, 2026

Uh oh!

thomass-dev commented Jun 8, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

glemaitre commented Jun 8, 2026

Uh oh!

thomass-dev commented Jun 8, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

thomass-dev Jun 8, 2026

Choose a reason for hiding this comment

Uh oh!

glemaitre Jun 8, 2026

Choose a reason for hiding this comment

Uh oh!

glemaitre Jun 8, 2026

Choose a reason for hiding this comment

Uh oh!

auguste-probabl Jun 9, 2026

Choose a reason for hiding this comment

Uh oh!

thomass-dev Jun 9, 2026

Choose a reason for hiding this comment

Uh oh!

auguste-probabl Jun 9, 2026

Choose a reason for hiding this comment

Uh oh!

thomass-dev Jun 9, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Choose a reason for hiding this comment

Uh oh!

auguste-probabl Jun 9, 2026

Choose a reason for hiding this comment

Uh oh!

Uh oh!

Uh oh!

glemaitre commented Jun 8, 2026

Uh oh!

rouk1 left a comment • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Uh oh!

Uh oh!

Uh oh!

jeromedockes commented Jun 9, 2026

Uh oh!

thomass-dev commented Jun 9, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

jeromedockes commented Jun 9, 2026

Uh oh!

thomass-dev commented Jun 9, 2026

glemaitre commented May 21, 2026 •

edited

Loading

github-actions Bot commented May 21, 2026 •

edited

Loading

thomass-dev commented Jun 8, 2026 •

edited

Loading

thomass-dev commented Jun 8, 2026 •

edited

Loading

thomass-dev Jun 9, 2026 •

edited

Loading

rouk1 left a comment •

edited

Loading

thomass-dev commented Jun 9, 2026 •

edited

Loading