Resolve release constraints against PyPI providers only - #71140
Merged
Conversation
A release pins the providers as published on PyPI. Building them from the sources first puts a locally built wheel where the resolution can find it, and anything answered locally is then left out of the constraints - dropping the very pin the release needed. It also makes the release depend on the provider build toolchain working, which is what broke 3.3.1rc1: flit removed --no-setup-py and package preparation failed before any resolution ran.
potiuk
requested review from
amoghrajesh,
ashb,
bugraoz93,
gopidesupavan,
jason810496 and
jscheffl
as code owners
August 5, 2026 03:50
boring-cyborg
Bot
added
area:dev-tools
backport-to-v3-3-test
vatsrahul1001
added
the
changelog:skip
vatsrahul1001
approved these changes
Aug 5, 2026
Contributor
Backport failed to create: v3-3-test. View the failure log Run detailsNote: As of Merging PRs targeted for Airflow 3.X In matter of doubt please ask in #release-management Slack channel.
You can attempt to backport this manually by running: cherry_picker c37ba12 v3-3-testThis should apply the commit to the v3-3-test branch and leave the commit in conflict state marking After you have resolved the conflicts, you can continue the backport process by running: cherry_picker --continueIf you don't have cherry-picker installed, see the installation guide. |
1 task
potiuk
added a commit
that referenced
this pull request
Aug 5, 2026
) A release pins the providers as published on PyPI. Building them from the sources first puts a locally built wheel where the resolution can find it, and anything answered locally is then left out of the constraints - dropping the very pin the release needed. It also makes the release depend on the provider build toolchain working, which is what broke 3.3.1rc1: flit removed --no-setup-py and package preparation failed before any resolution ran. (cherry picked from commit c37ba12) Co-authored-by: Jarek Potiuk <jarek@potiuk.com>
1 task
vatsrahul1001
added a commit
that referenced
this pull request
Aug 5, 2026
) A release pins the providers as published on PyPI. Building them from the sources first puts a locally built wheel where the resolution can find it, and anything answered locally is then left out of the constraints - dropping the very pin the release needed. It also makes the release depend on the provider build toolchain working, which is what broke 3.3.1rc1: flit removed --no-setup-py and package preparation failed before any resolution ran. (cherry picked from commit c37ba12) Co-authored-by: Jarek Potiuk <jarek@potiuk.com>
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
2 participants
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.
release-constraints.ymlproduces the constraints a release ships, which pin every provider at the version published on PyPI. It was still building the providers from the sources in the checkout first.That is wrong in two ways. The built wheels land in the dist directory that the PyPI resolution reads through
--find-links, so a locally built wheel can answer for a provider — andget_locally_build_distribution_specs()then excludes anything answered locally from the constraints file. The provider the release most needed pinned is the one that ends up missing. It is the right behaviour while developing a provider that is not on PyPI yet; it is the opposite of what a release wants.It also makes cutting constraints depend on the provider build toolchain working. That is what broke the 3.3.1rc1 run:
flitremoved--no-setup-py,prepare-provider-distributionsfailed on all five Python versions, and generation died before any resolution ran.A new
pypi-providers-onlyinput ongenerate-constraints.yml(defaultfalse, so nothing else changes) skips both the source-providers constraints and the provider distribution build.release-constraints.ymlsets it. Combined with thegenerate-no-providers-constraints: "false"already there, a release run now generates only the PyPI constraints.The airflow and task-sdk distributions are still built — a release resolves
apache-airflow==<version>before that version exists on PyPI, so those have to come from--find-links.Was generative AI tooling used to co-author this PR?
Generated-by: Claude Opus 5 (1M context) following the guidelines