gh-152384: pixi-packages: use flags to define variants#152385
gh-152384: pixi-packages: use flags to define variants#152385lucascolley wants to merge 12 commits into
flags to define variants#152385Conversation
| - `freethreading` | ||
| - `asan`: ASan-instrumented build | ||
| - `tsan-freethreading`: TSan-instrumented free-threading build | ||
| - `tsan_freethreading`: TSan-instrumented free-threading build |
There was a problem hiding this comment.
I think it makes sense to remove the - from this variant name, given that it is invalid in the flags field: https://conda.org/learn/ceps/cep-0045#repodata-record-syntax
There was a problem hiding this comment.
seems fine to me, I think you and @crusaderky are just about the only users of these builds so far for what its worth
| run_exports: | ||
| noarch: | ||
| - python | ||
| weak: | ||
| - python_abi ${{ version }}.* *_${{ abi_tag }} |
There was a problem hiding this comment.
we could also define flags on python_abi and perhaps not need to rely on abi_tag as much? But I suppose we still want to keep abi_tag around at least while conda-forge does?
EDIT: can probably leave this for a follow-up and open an issue
|
@StanFromIreland this goes some way towards making the version update situation better by reducing duplication in the variant definition |
| openssl: | ||
| - '3.5' |
There was a problem hiding this comment.
ref. prefix-dev/pixi#6460 (comment) @h-vetinari, I wonder whether there is a better way to do this by pulling in (some of?) https://github.com/conda-forge/conda-forge-pinning-feedstock/blob/main/recipe/conda_build_config.yaml
There was a problem hiding this comment.
obviously you could download the current pinning file, yaml-load it and extract the openssl pin, but that's perhaps more complexity and dynamism than justified - an argument could be made that openssl is special enough to handle it separately... and although pins have a habit of going stale, staying on an LTS version probably makes sense here.
conda-forge will probably migrate to openssl 4 in the fall, but since AFAICT python has no other dependencies that are themselves openssl-dependent, this should not cause any conflicts (except in larger environments with the most recent builds, but that's not really relevant for the ASAN stuff).
There was a problem hiding this comment.
obviously you could download the current pinning file, yaml-load it and extract the openssl pin, but that's perhaps more complexity and dynamism than justified
an idea was floated at some point that variant configs themselves could be packaged as conda packages and Pixi could consume them that way. Not sure if anyone has thought about that recently.
There was a problem hiding this comment.
I mean, conda-forge-pinning is exactly that package. You'd still have to go parse the yaml though. 🤷
|
The CI failure looks unrelated but before this PR can be merged it's going to need a NEWS entry. Can you add one? |
|
I've updated this branch from |
|
news added |
|
@ngoldbaum @kumaraditya303 any remaining concerns from your side? I think we can merge and patch up any more changes in a follow-up, this seems to be an improvement on the situation in |
Co-authored-by: Isuru Fernando <isuruf@gmail.com>
Co-authored-by: Isuru Fernando <isuruf@gmail.com>
Co-authored-by: Isuru Fernando <isuruf@gmail.com>
ngoldbaum
left a comment
There was a problem hiding this comment.
What happens if someone doesn't provide a variant flag? Which one is selected? None? Is there a good error? Should this be explicitly mentioned in the readme?
I left some more comments inline.
| - expat | ||
| - if: linux and "san" in variant | ||
| then: | ||
| - libsanitizer |
There was a problem hiding this comment.
Is this still needed now that we're using clang everywhere?
There was a problem hiding this comment.
Okay yeah, I presume it is GCC-specific and thus not needed.
| openssl: | ||
| - '3.5' | ||
|
|
||
| c_compiler: | ||
| - clang | ||
| c_compiler_version: | ||
| - 21 | ||
| cxx_compiler: | ||
| - clangxx | ||
| cxx_compiler_version: | ||
| - 21 |
There was a problem hiding this comment.
can we add comments explaining these pin choices?
There was a problem hiding this comment.
@kumaraditya303 how would you explain when these need to be updated, and where to look for the new versions?
There was a problem hiding this comment.
@kumaraditya303 how would you explain when these need to be updated, and where to look for the new versions?
There was a problem hiding this comment.
Who suggested it, and was it for to avoid a bug in newer clang, for reproducibility, or for building the JIT in the future (that needs LLVM 21, but the JIT isn't covered by the build variants today, and I'd think any recent version should work for default/free-threaded/asan/tsan builds)?
There was a problem hiding this comment.
how would you explain when these need to be updated, and where to look for the new versions?
Ideally it should match the version of clang used in https://github.com/python/cpython/blob/main/.github/workflows/reusable-san.yml, so if that file is updated pixi definitions should be updated as well.
Co-authored-by: Nathan Goldbaum <nathan.goldbaum@gmail.com>
Good catch. I think we may want to use |
cc @wolfv @baszalmstra @jaimergp I'm very excited about this PR!
pixi.toml#152384