Design doc: a more complex, pixi - native `when` for conditional dependencies

[wolfv]

We have discussed (@baszalmstra and me) how to design a pixi-native when (in the context of supporting v3 repodata that includes conditional dependencies). This is especially relevant for pixi-build.

CEP: conda/ceps#164

In the raw matchspec, when can look something like:

foobar [when="python >=3.10"]
foobar [when="python and numpy"]
foobar [when="python or nodejs"]

Where the individual elements fo the expression can be full blown matchspecs again (except nested when is not allowed!).

For a Pixi / TOML native version, we came up with the following idea:

Allow single name, e.g:

foobar = { version = "*", when = "python" }

For more complex matchspec:

foobar = { version = "*", when = { python = ">3.10" } }

To support and / or:

# We use an array, and combine with AND by default (can be made explicit)
foobar = { version = "*", when = [{ python = ">3.10" }, "numpy" ] }
foobar = { version = "*", when = [{ python = ">3.10" }, { numpy = ">2"}] }
foobar = { version = "*", when = [{ python = ">3.10" }, "&&", { numpy = ">2"}] }

# for OR
foobar = { version = "*", when = [{ python = ">3.10" }, "||", { numpy = ">2"}] }

[ruben-arts]

I would go for a direct translation from the matchspec. No extra TOML.

python = { when = "what ever is allowed in the matchspec when" }

This makes copy and pasting much easier. And there is no new syntax needed.

[travishathaway]

I agree with @ruben-arts. That list syntax ([ ... ]) gets ugly really quick when the conditionals get more complex.

[wolfv]

Thanks for chiming in. I'd personally also be happy with using the raw first. It becomes a bit ugly when you go for more complicated matchspecs (matching on build string, flags, ...). Then it departs a bit from our TOML syntax.

A downside of the proposed syntax is that we cannot express brackets btw.

Let's see if Bas can be convinced.

[baszalmstra]

A downside of the proposed syntax is that we cannot express brackets btw.

Why not?

foobar = { version = "*", when = { python = { build = "*freethreading*" } }

[GuillaumeQuenneville]

The pixi specific syntax would let us add some considerations that aren't part of the conda matchspecs.

mydep = { version = "*", build ="*cuda*", when = { pixi_feature = "gpu" or variant = "gpu"}}

[baszalmstra]

I would go for a direct translation from the matchspec. No extra TOML.

I can see why this is useful, but it means we allow generic matchspecs in the pixi.toml, which is something that is much harder to parse for a machine than TOML. There is no schema validation, there are no completions, and errors become harder to report. If we can avoid that, I would prefer it.

I also doubt people will often use very complex when expressions. I think most will fall into the category of:

foobar = { version = "*", when = "__unix" }
foobar = { version = "*", when = { python = ">=3.11" } }

[wolfv]

I meant we cannot do round brackets / parentheses to group and/or statements.

[baszalmstra]

Sure, we can!

foobar = { version = "*", when = ["foo", "&&", ["bar", "||", "baz"]] }

Edit: I noticed that not all TOML libraries support mixing array element types.. So maybe this is not true.

[wolfv]

I don't know if it is really worth the extra effort. How about the following:

• we allow "full" expressions as a string (includes simple ones as well)
• we also allow a dictionary for the nicer syntax, but it won't allow and, or or - for those you'll need to write a full expression

So you could do:

foobar = { version = "*", when = "__unix" }
foobar = { version = "*", when = { python = ">=3.10" }}
foobar = { version = "*", when = "python >=3.10 and __unix" }

[baszalmstra]

But then we take on the burden of both approaches. That also doesn't sit right with me.

[ruben-arts]

I think our matchspec parsing is already nice enough to make useful parsing errors. I would not spend the extra effort even though an AI would build it, we still have to test and maintain it.

[lucascolley]

I don't know if it is really worth the extra effort. How about the following:

• we allow "full" expressions as a string (includes simple ones as well)
• we also allow a dictionary for the nicer syntax, but it won't allow and, or or - for those you'll need to write a full expression

So you could do:

foobar = { version = "", when = "__unix" }
foobar = { version = "", when = { python = ">=3.10" }}
foobar = { version = "*", when = "python >=3.10 and __unix" }

This is what I was going to suggest before reaching this comment in the thread, yes.

But then we take on the burden of both approaches. That also doesn't sit right with me.

I would be happy with just one being supported in the first instance, and generalising to both if there is user-demand. Which one, I don't have a strong opinion.