Define dependencies conditioned on Python version in pixi.toml?

[MatthewSZhang]

In pyproject.toml, we can define the build dependencies like below

[build-system]
requires = [
    "scikit-learn>=1.6.0",
    "meson-python>=0.18.0; python_version > '3.9'",
    "Cython>=3.1.0; python_version > '3.9'",
    "meson-python==0.16.0; python_version == '3.9'",
    "Cython==3.0.10; python_version == '3.9'",
]
build-backend = "mesonpy"

But in pixi.toml, can we define dependencies conditioned on Python version?

Currently I use feature.py39.dependencies to overwrite the default.dependencies, like below

[dependencies]
python = ">=3.9"
scikit-learn = ">=1.6.0"
cython = ">=3.0.10" # build dependencies
meson-python = ">=0.16.0" # build dependencies

[feature.py39.dependencies]
python = "==3.9.0"
scikit-learn = "==1.6.0"
meson-python = "==0.16.0"
cython = "==3.0.10"

[bollwyvl]

There is an on-going discussion on CEP-111 for adding this behavior ecosystem-wide in general (not just pixi, and not just the special case of python), but as the sprawling scope of that suggests, it will probably take a while.

Even if that does land, the "list of increasingly-complex-matchspecs with duplicate names" syntax isn't going to play very nicely with pixi's generally more sensible "set of named deps." An incomplete numpy example for pixi is shown in that CEP, which doesn't even look like it would cover the case shown here.

So today: a dedicated feature is the way. Indeed, the repeated # build dependency comments suggests even another feature might be more precise: one really wouldn't want to mistakenly base a passing test on the presence of a build-time transitive dependency.

[baszalmstra]

@bollwyvl is right, features are the way atm.

But im sure we will be supporting conditional dependencies (and more) as described in the CEP in the near future. We "just" need to figure out the syntax for it in TOML. We already have the technology to support this CEP done.

[bollwyvl]

Yep, devil's in the "just".

Spitballing syntax, I could see something like the following working where the dependencies/oneOf was expanded in the schema to permit a list of constraints, all of which that evaluate to something need to be satisfied:

[feature.build.dependencies]
cython = [">=3.0.10", {if={python = "3.9.*"}, then="==3.0.10"}]
meson-python = [">=0.16.0", {if={python = "3.9.*"}, then="==0.16.0"}]

Note the duplication (as with the pyproject.toml example) of the if condition. Anything more "clever" is probably going to still be more readable as a feature, as then 3.9.* is would only need to be written once (though the feature name will have to be written).

Of note, in this specific case, feature.solve-strategy = "lowest-direct" would probably already work, but this isn't going to scale to the insane cases people will think up when they can limit anything based on anything (and probably in cycles). I've taken to making a "phony" feature that carries that along:

[feature.build.dependencies]
python = ">=3.9"
cython = ">=3.0.10"
meson-python = ">=0.16.0"

[feature.lowest-direct]
solve-strategy = "lowest-direct"

[enviroments]
build = ["build"]
build-lowest = ["build", "lowest-direct"]