-
Notifications
You must be signed in to change notification settings - Fork 104
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Make recent manylinux wheels findable by pypi_resolver #541
Conversation
✅ Deploy Preview for conda-lock ready!
To edit notification comments on pull requests, go to your Netlify site configuration. |
assert manylinux_match, "No match found for manylinux version in {lightgbm_dep.url}" | ||
|
||
manylinux_version = [int(each) for each in manylinux_match.groups()] | ||
assert manylinux_version > [2, 17] |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Is line 2321 a "documentation"-type assertion or an actual test? In the latter case, what are we trying to check? (Like what would be the failure mode?)
I'm assuming that we only detect manylinux_version
s which are in both MANYLINUX_TAGS
and match the regex, and so this looks somewhat tautological.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I am making sure that not we find a "recent" manylinux wheel i.e. more recent than manylinux_2_17, since manylinux_2_17 was was already handled by conda-lock before this PR.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I tweaked the docstring and add a comment to try to make that more explicit
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Ah, ok, I think I get it now: before this PR the solver might have either:
- chosen the wheel with the latest
lightgbm
version, which is what happened in conda-lock pip dependency gets .tar.gz sdist rather than manylinux wheel when available manylinux wheel is more recent than 2_17 #517 - chosen an earlier version of
lightgbm
for which amanylinux_2_17
wheel exists (not actually happening in any case, but theoretically possible)
Please correct me if I'm misunderstanding, and thanks for the clarification!
Co-authored-by: Ben Mares <services-git-throwaway1@tensorial.com>
PR conda#541 added support for finding wheels with GLIBC 2.28. However, as rightly pointed out in that PR: "Note this could pose an issue if the glibc on the machine you are doing conda lock install does not have a recent enough glibc" This PR aims to solve this issue by propagating the GLIBC version specified through the virtual package spec to Conda all the way down to the pypi solver. To make all tests pass, the default GLIBC version is also raised to 2.28. We could alternatively keep it fixed and provide a virtual-packages.yml file for the test in PR conda#541 but it feels like both "defaults" should be the same (for pip and conda).
PR conda#541 added support for finding wheels with GLIBC 2.28. However, as rightly pointed out in that PR: "Note this could pose an issue if the glibc on the machine you are doing conda lock install does not have a recent enough glibc" This PR aims to solve this issue by propagating the GLIBC version specified through the virtual package spec to Conda all the way down to the pypi solver. To make all tests pass, the default GLIBC version is also raised to 2.28. We could alternatively keep it fixed and provide a virtual-packages.yml file for the test in PR conda#541 but it feels like both "defaults" should be the same (for pip and conda).
Description
Fix #517. For now I have added 2 manylinux tags, for which manylinux provides a Docker image. I am guessing they are the most used manylinux wheels for recent wheels (i.e. more recent than manylinux2014, which is the same as manylinux_2_17).
Having said that other wheels likely exist in the wild, e.g. #395 is a 2_27 wheel. An alternative would be to list all the possible versions between
2_17
and2_28
(the latest Docker image provided by manylinux).Note this could pose an issue if the glibc on the machine you are doing
conda lock install
does not have a recent enough glibc. As a data point, Ubuntu 18.04 (not supported any more) has glibc 2.27, Ubuntu 20.04 has glibc 2.31.I have added a test as well using lightgbm and making sure that the resolved url points to a wheel that is more recent than (2, 17).