Decouple default glibc from MANYLINUX_TAGS maximum - #903
Open
maresb wants to merge 4 commits into
Open
Conversation
The test_manylinux_tags test incorrectly asserted that the default glibc version must equal the maximum of MANYLINUX_TAGS. This forced contributors to bump the default glibc whenever adding a new tag, even though these are independent concerns: the default glibc is a conservative policy for the target system, while MANYLINUX_TAGS entries are capabilities available via --virtual-package-spec. Relax the assertion to set inclusion (default glibc versions must be covered by MANYLINUX_TAGS) and remove the misleading "keep in sync" comments that guided contributors toward the wrong invariant. Made-with: Cursor
Explain in default-virtual-packages.yaml and README.md that each virtual package version acts as an upper bound on candidate packages and a lower bound on compatible target systems. Made-with: Cursor
Replace the technical jargon about "injecting" and "gating on system features" with a clearer explanation of what virtual packages are, what the version numbers mean, and how to adjust them. Made-with: Cursor
Apply the same documentation improvements to the docs site version of the --virtual-package-spec section. Made-with: Cursor
|
You have used all of your free Bugbot PR reviews. To receive reviews on all of your PRs, visit the Cursor dashboard to activate Pro and start your 14-day free trial. |
✅ Deploy Preview for conda-lock ready!
To edit notification comments on pull requests, go to your Netlify project configuration. |
3 tasks
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Human-written content:
Back in the day, @romain-intel and I added a test in #566 that in retrospect I believe was in error. The problem is "Verify that the default repodata uses the highest glibc version" in
test_manylinux_tagsbecause it imposes what I believe is an artificial constraint on the glibc version: that the default glibc version must track the latest glibc version.In order to understand why I believe this constraint is artificial, it's necessary to have a clear view of what the virtual package versions represent. I personally find the concept very confusing. Thinking hard about what I found confusing, realized that it's because the versions specified are functioning simultaneously as an upper-bound (for filtering) and a lower-bound (for system compatibility), and hence represent a tradeoff. I tried to rewrite the documentation in plain language to make it easier to understand the crux:
So the problem I see with the test is that if we max out the default virtual package glibc version, then we generate lockfiles that may contain packages that require this high glibc version, and hence are uninstallable on systems for which the glibc version is lagging. I believe the optimal default virtual package versions should be a middle ground to avoid both tradeoff extremes.
I don't think we should increase the default glibc version as part of #900, and looking at why the version was bumped there, I believe it was due to this test. So I'm hoping here to fix the root cause of the confusion via documentation, and also to fix the test so that the right compromise remains possible with the defaults.
LLM content:
Summary
test_manylinux_tagsassertion from==to set inclusion (<=): the default glibc versions must be covered byMANYLINUX_TAGS, but the max tag can exceed the defaultdefault-virtual-packages.yaml,README.md, anddocs/flags.mdMotivation
The previous test and comments incorrectly coupled two independent concerns:
default-virtual-packages.yaml): a conservative assumption about the target system — should be kept low (e.g., 2.28, matching Pixi's default)pypi_solver.py): the highest manylinux tag the solver understands — can be higher than the default, since users can opt in via--virtual-package-specThe old invariant forced contributors to bump the default glibc whenever adding a new manylinux tag (see #900), which would silently change solver behavior for all users and risk producing lockfiles incompatible with older glibc systems.
The correct invariant is: every default glibc version must appear in
MANYLINUX_TAGS(set inclusion), but the max tag can exceed the default.Context: #847 (discussion about dynamically generating tags), #566 (original manylinux filtering), #900 (motivated this fix)
Test plan
test_manylinux_tagspasses with the relaxed assertionMade with Cursor