feat: support if(...) conditional package dependencies#6269
Conversation
8b45cf3 to
d01ad12
Compare
d01ad12 to
8e47274
Compare
8e47274 to
62e0808
Compare
|
@baszalmstra I've adapted a lot of tests to use the pass-through backend instead and removed the example satisfiability tests as we discussed. However, I am a bit unsure about your "simple_test", maybe you can check this one out |
6ea014b to
f869de9
Compare
|
Will this support all the parameters / virtual packages from the specificiers "rich" platforms pr? #4458 I am particularly interested in using at the moment the way to swap between cuda and non cuda dependencies is through the pixi environments. This works for workspaces but not for building packages. There is no syntax at the package level to define "these deps if CPU, these deps if GPU" as far as i know without going to rattler-build. in the example you added in the latest commit. how do you specify to a cuda and non-cuda variant for windows and linux? This example would break for all workspace users on a machine without an nvidia gpu since they dont have the __cuda virtual package. |
|
TODO for myself:
|
1cda39a to
d74b55f
Compare
| A minimal C++ package that shows off `if(...)` conditional dependencies in a | ||
| Pixi `[package]` section. | ||
|
|
||
| `cuda_probe` is a tiny executable that reports which compiler built it and |
There was a problem hiding this comment.
cuda toolkit is installable on systems without cuda drivers and the CMakeLists only checks for presence of cuda toolkit. From my understanding, users on win and linux would build unuseable cuda binaries that crash due to missing drivers instead of falling back to the CPU build.
it would be useful if the example showed how to use build variants to have a CPU and CUDA version. And how switch between them on Windows and Linux depending on the presence of the __cuda virtual package.
c1b4923 to
c0ae5b7
Compare
Add support for conditional dependencies in the [package] section using an if(<expression>) key inside the dependency tables, e.g. [package.build-dependencies."if(host_platform != build_platform)"]. The expression is not evaluated by pixi; it is modelled as a dedicated ConditionalExpression type in the project model, separate from platform target selectors, and passed through verbatim to rattler-build as part of pixi-build-api-version 5. The legacy [package.target.*] tables keep working but emit a deprecation warning that spells out the equivalent if(...) tables, and they are removed from the JSON schema. Workspace [target.*] tables reject expression selectors with an error pointing at the package dependency tables. The passthrough test backend has no jinja evaluator and panics on if(...) conditionals instead of silently dropping them.
Cover a simple platform family condition, a complex boolean expression, a match() condition evaluated against build variants and the error message for an expression that does not parse. Extend target_specific_channel_1 with stub cmake and ninja packages so the build environment of pixi-build-cmake can be solved offline.
584327f to
1aba46e
Compare
Description
Add support for conditional dependencies in the
[package]section using anif(<expression>)key inside the dependency tables, e.g.[package.build-dependencies."if(host_platform != build_platform)"]. The expression is passed through to rattler-build. The old[package.target.*]syntax keeps working but emits a deprecation warning.Fixes #4625
How Has This Been Tested?
pixi run testAI Disclosure
Tools: {e.g., Claude, Codex, GitHub Copilot, ChatGPT, etc.}
Checklist:
schema/model.py.