Proposal for Pixi workflow

[AntoinePrv]

This is the proposed Pixi workflow

Tasks:

• Add pixi.toml
• Add CMakePresets
• Add usage to documentation
• Add sample usage in CI

Some notes and possible improvements:

• The CMakePresets.json is a bit verbose but I prefered to keep it modular so that we can derive all useful presets. It would be nice to make it converge with the options in CI so that it can be use there too. This is low risk since it is simply a different way to configure the same options.
• On the CI workflow sample: along with the official setup-pixi GH action that caches dependencies, this is a very powerful way to run a lot of configurations. If the first job works well, it could also be used to run some simple gcc/clang configurations.

Close #1209

[DiamonDinoia]

can you try https://github.com/DiamonDinoia/xsimd/tree/pixi-workflow-fix

it is not infinite recursion because of SFINAE. All of this can be greatly simplified with c++17 once available :)

[AntoinePrv]

@DiamonDinoia yes runs smoothly for me: I tried clang-18, clang-21 and gcc-15 🙏

[AntoinePrv]

@serge-sans-paille what do you think of this?

[serge-sans-paille]

I assume (and hope) this file should not be checked in?

[AntoinePrv]

Well it depends. Nowadays it is not uncommon to check in lockfiles in the repository to use them in CI.
This one is rather large because we create all these different compilers environments.
To use pixi in CI, I would say we should keep it because it avoids solving end make caching easier. However we can still do without I believe (need to try out other options). Your call.

[AntoinePrv]

Note that this can also be hidden by default in github PRs (and stats I believe).
https://docs.github.com/en/repositories/working-with-files/managing-files/customizing-how-changed-files-appear-on-github

[AntoinePrv]

Requesting your feedback again @serge-sans-paille.

I personally don't think the lock file is an issue, it's pretty common nowadays. However if we take it out, I would also disable the CI.

[AntoinePrv]

I see the Github action is failing due to missing docker image, perhaps this could be the opportunity to use pixi for running clang-format and other static analyzers ;)

[AntoinePrv]

@serge-sans-paille if you don't have strong objections, I would like to get this one in, along with the lockfile which should not change unless we modify things and is hidden from diff.

[serge-sans-paille]

I'm honestly not a fan of tool-specific configuration in the main repo (now pixi, then what? Dockerfiles ?).
And even less of a fan of keeping the lock/cache file in-tree.
For CI, this will bring more reproducibility, but maybe we want diversity in CI too, or at least something closer to dev environment instead of normalizing it?

Sorry for not being thrilled by this PR, we already have a lot of commit noise due to CI, I'd like to not too increase that :-/

[AntoinePrv]

I'm honestly not a fan of tool-specific configuration in the main repo (now pixi, then what? Dockerfiles ?).

I think we owe to contributors to have one way of getting started quickly. It could have been Dockerfiles, or perhaps Nix, or anything. I find this one to be low friction (it's declarative, has the same usage on all platforms, and does not take update-alternatives modifying global user system for the use of a single project). It is also a stack that we understand pretty well.
Documentation is not a good solution IMHO as it is not tested automatically and get outdated fast.

And even less of a fan of keeping the lock/cache file in-tree.

It's not pretty, but it speed things up, and time is important too.

but maybe we want diversity in CI too

I agree with this, and I did not mean to replace all CI at all. For diversity, we should in fact include some conda-forge builds. But I was mostly thinking of streamlining things like

• sudo apt install clang-tools which is not pinned to any version
• python3 -m pip install ninja which is kind of weird
• unknown version cmake from Github's own runners etc
• other tools we may wish to add: cmake-format, typos, maybe conventional commit tooling etc.

I'd add a grain of salt though. Diversity is good, and we want to check many settings, but the goal is also not to check that cmake or gcc-15 are properly working across all distributions. We're testing xsimd, not the tools.

or at least something closer to dev environment instead of normalizing it

I'm not sure what you mean. I did not mean to impose this workflow. In fact it is very much optional in this PR.

Sorry for not being thrilled by this PR, we already have a lot of commit noise due to CI, I'd like to not too increase that :-/

I understand, I also don't like working on CI. That's why I like approaches where I can reproduce as much as possible locally without many steps, or without making system-level changes (additionally without CI provider lock-ins).
I will never get 100% the same, especially some things are not worth the effort to setup on our own (MSVC, AppleClang...). But at least using the same tools, I know there are no CDN issue, no misconfiguration, no script that silently fails somewhere etc. and keep CI failure for things worth noticing.

[serge-sans-paille]

I wanted to get deeper knowledge of pixi, and started with

$ pixi tree
  × failed to parse project manifest
    ╭─[pixi.toml:22:2]
 21 │ # https://pixi.sh
 22 │ [workspace]
    ·  ────┬────
    ·      ╰── unknown field `workspace`, expected one of `project`, `system-requirements`, `target`, `dependencies`, `host-dependencies`, `build-dependencies`, `pypi-dependencies`, `activation`, `tasks`, `feature`, `environments`, `pypi-options`, `tool`, `$schema`
 23 │ channels = ["conda-forge"]
    ╰────

not a good start /o\

[AntoinePrv]

First thank you for giving it a try ! As for the error, you must be running an outdated version of pixi.