gh-152384: pixi-packages: use flags to define variants#152385
Conversation
| - `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>
Good catch. I think we may want to use |
|
@ngoldbaum @hugovk I believe this is ready for a final look! |
ngoldbaum
left a comment
ngoldbaum
left a comment
There was a problem hiding this comment.
Other than the issue with the error message, LGTM!
Co-authored-by: Nathan Goldbaum <nathan.goldbaum@gmail.com>
|
This looks good, I'll merge it now to unblock other stuff. |
|
How far do we want to backport this? Or just I generally prefer to have less diverse config across branches, as it makes it harder to maintain. |
|
Either way works I think, it shouldn't break anything to backport. Both because it's still very new with only a few users, and because the main way of using it is to point at an exact commit hash in a downstream |
|
a backport to 3.15 would be nice, however https://github.com/python/cpython/blob/main/Tools/pixi-packages/variants.yaml#L1 will need a tweak |
7 participants
cc @wolfv @baszalmstra @jaimergp I'm very excited about this PR!
pixi.toml#152384