dev/breeze/pyproject.toml caps flit and flit-core below 4, so provider distributions keep being built by the backend CI has actually exercised. The cap should come off as part of a deliberate flit 4 adoption, not by relaxing the specifier on its own.
Why the cap is there
flit build does not use PEP 517 build isolation — flit/wheel.py is import flit_core.wheel as core_wheel, so the backend is whichever flit_core is installed in the environment. That makes the flit_core==3.12.0 pin every provider declares in [build-system] requires inert on the path we release from, and leaves breeze's own dependency as the only thing deciding it. Because that dependency was an unbounded floor, flit 4.0.1 became the provider build backend within minutes of being published, without anyone choosing it.
flit 4 is not a drop-in for that role. It emits core metadata 2.5 with the new Import-Name and Import-Namespace fields, makes --no-use-vcs the default for sdists, and applies the tar data filter on Python 3.12+. None of that has been exercised against Airflow's provider distributions or its reproducible-build checks.
Both distributions need the cap: flit 4.x requires flit_core>=4, and flit 3.12.0 requires flit_core>=3.12.0 with no upper bound, so capping only flit would still admit the 4.x backend.
The defect that exposed this — flit_core 4.0.1 writing Import-Name without a trailing newline, which cost the resulting METADATA its header/body separator — was fixed upstream in pypa/flit#813 and released as 4.0.2. It is no longer a reason to hold the cap; the unvalidated backend change is.
Follow-up work
Validate flit 4 as the provider build backend — metadata 2.5 acceptance by the tooling that consumes provider distributions, sdist contents with --use-vcs still passed explicitly, and reproducible-build output — then move flit, flit-core and the per-provider flit_core== pins together through scripts/ci/prek/upgrade_important_versions.py.
Note that the script rewrites these specifiers in place by version number, so a bump would turn flit>=3.12.0,<4 into flit>=4.0.1,<4. The same hazard already exists for the flit_core >=3.12.0,<4 cap on breeze's own build backend, and is worth fixing when the caps are revisited.
Acceptance criteria
- Provider wheels and sdists built with flit 4 match what 3.12.0 produces apart from the intended metadata additions.
Generate constraints, Providers sdist tests, Providers wheel tests and the Compat jobs are green.- The specifiers in
dev/breeze/pyproject.toml are floors again, moved by the upgrade script alongside the provider flit_core== pins, and the tracking comment at the cap site is removed.
Drafted-by: Claude Code (Opus 5)
dev/breeze/pyproject.tomlcapsflitandflit-corebelow 4, so provider distributions keep being built by the backend CI has actually exercised. The cap should come off as part of a deliberate flit 4 adoption, not by relaxing the specifier on its own.Why the cap is there
flit builddoes not use PEP 517 build isolation —flit/wheel.pyisimport flit_core.wheel as core_wheel, so the backend is whicheverflit_coreis installed in the environment. That makes theflit_core==3.12.0pin every provider declares in[build-system] requiresinert on the path we release from, and leaves breeze's own dependency as the only thing deciding it. Because that dependency was an unbounded floor, flit 4.0.1 became the provider build backend within minutes of being published, without anyone choosing it.flit 4 is not a drop-in for that role. It emits core metadata 2.5 with the new
Import-NameandImport-Namespacefields, makes--no-use-vcsthe default for sdists, and applies the tardatafilter on Python 3.12+. None of that has been exercised against Airflow's provider distributions or its reproducible-build checks.Both distributions need the cap:
flit4.x requiresflit_core>=4, andflit3.12.0 requiresflit_core>=3.12.0with no upper bound, so capping onlyflitwould still admit the 4.x backend.The defect that exposed this — flit_core 4.0.1 writing
Import-Namewithout a trailing newline, which cost the resultingMETADATAits header/body separator — was fixed upstream in pypa/flit#813 and released as 4.0.2. It is no longer a reason to hold the cap; the unvalidated backend change is.Follow-up work
Validate flit 4 as the provider build backend — metadata 2.5 acceptance by the tooling that consumes provider distributions, sdist contents with
--use-vcsstill passed explicitly, and reproducible-build output — then moveflit,flit-coreand the per-providerflit_core==pins together throughscripts/ci/prek/upgrade_important_versions.py.Note that the script rewrites these specifiers in place by version number, so a bump would turn
flit>=3.12.0,<4intoflit>=4.0.1,<4. The same hazard already exists for theflit_core >=3.12.0,<4cap on breeze's own build backend, and is worth fixing when the caps are revisited.Acceptance criteria
Generate constraints,Providers sdist tests,Providers wheel testsand theCompatjobs are green.dev/breeze/pyproject.tomlare floors again, moved by the upgrade script alongside the providerflit_core==pins, and the tracking comment at the cap site is removed.Drafted-by: Claude Code (Opus 5)