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

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?

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

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).

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.

I mean, conda-forge-pinning is exactly that package. You'd still have to go parse the yaml though. 🤷