Add manylinux_2_34 to supported MANYLINUX_TAGS#900
Conversation
✅ Deploy Preview for conda-lock ready!
To edit notification comments on pull requests, go to your Netlify project configuration. |
Update expected hashes in test_default_virtual_package_input_hash_stability and test_default_virtual_package_input_hash_stability_cuda_version to reflect the new glibc 2.34 default. Old glibc 2.28 hashes are preserved in backward compatibility checks.
Add _replace_glibc_version to backwards_compatible_content_hashes so that lockfiles generated with the old glibc 2.28 default are still recognized as valid after bumping to 2.34. Update HASHES_V2 in the v2-to-v3 upgrade test to match the new default.
Use cast(SubdirMetadata, ...) instead of type: ignore comment, and use model_copy(deep=True) consistent with rest of file.
|
@maresb curious to hear your thoughts on this PR. thank you! |
|
Hi @guenp, apologies for the late review. Looking this over, I think this PR became overcomplicated due to a preexisting flaw in our tests going back to #566. I document and attempt to fix this flaw in #903. Would you please look that over and see if that makes sense to you? Regarding this PR, assuming that we merge #903, then I think it's sufficient as a temporary fix to simply add the corresponding 2.34 entry to MANYLINUX_TAGS. I think this would be a 1-line PR. (Sorry for all the unnecessary complexity you faced in the current draft, but at least this led me to open #903.) As for a more sustainable solution, I think we can just remove Is this something you'd be interested in tackling? |
|
@romain-intel, if you're available I'd love to get your take on this! |
2 participants
Summary
_2_34toMANYLINUX_TAGSinpypi_solver.py__glibcfrom2.28to2.34indefault-virtual-packages.yamlfor all Linux subdirsFollow-up to #847, which added
_2_18.Motivation
pyqir 0.12.3 only publishes Linux wheels for
manylinux_2_34(x86_64) andmanylinux_2_38(aarch64). SinceMANYLINUX_TAGScurrently maxes out at_2_28, conda-lock's PyPI solver rejects these wheels:The
--virtual-package-specworkaround doesn't help because even if__glibcis set to2.34, the hardcoded tag list doesn't include_2_34.Discussion
I'm open to discussing a better long-term solution — e.g., dynamically generating valid manylinux tags from the glibc version rather than maintaining a hardcoded list. Happy to iterate on this.
Test plan
--virtual-package-specwith__glibc: "2.34"works end-to-end