Dev-iL commented on code in PR #74696:
URL: https://github.com/apache/airflow/pull/74696#discussion_r4310851664
##########
pyproject.toml:
##########
@@ -119,7 +119,7 @@ apache-airflow = "airflow.__main__:main"
"apache-airflow-providers-apache-beam>=5.8.1"
]
"apache.cassandra" = [
- "apache-airflow-providers-apache-cassandra>=3.7.0; python_version
!=\"3.14\""
+ "apache-airflow-providers-apache-cassandra>=3.7.0"
Review Comment:
I tried raising the floor and backed it out — it can't work in this PR, and
the reason turns out to be structural rather than a matter of picking the right
number.
`generate_constraints_pypi_providers` resolves with every active provider
pinned exactly at the newest version PyPI holds for the Python being built:
```
uv pip install --exact --strict --resolution highest \
apache-airflow[all]==<dev version> \
<every active provider>==<newest installable on PyPI> \
--find-links file://dist
```
On 3.11-3.13 that hands the resolver
`apache-airflow-providers-apache-cassandra==3.10.1`, which contradicts any
extras floor above 3.10.1 outright. The pin comes from PyPI rather than from
`dist`, so building the provider locally doesn't help, and no choice of number
does either. On 3.14 `find_newest_version_in_pypi` returns `None`, since every
published release carries `!=3.14.*`, so Cassandra is left unpinned and
resolution falls back to PyPI plus the locally built wheel — which is why the
step passes at `>=3.7.0` today and failed on all four Pythons at `>=3.11.0`.
The mechanism that *would* fit is `# use next version`: leave the floor
where it is and let the release automation rewrite it once the provider version
has been bumped, so CI never sees a floor that isn't published. It doesn't
reach here, for two reasons:
- `update_providers_with_next_version_comment()` globs
`AIRFLOW_PROVIDERS_ROOT_PATH/**/pyproject.toml`, and the meta-package isn't
under `providers/`, so it is never scanned.
- The extras lines are regenerated by `update_airflow_pyproject_toml.py`,
whose line format carries only the `MIN_VERSION_OVERRIDE` comment. I tried
adding `# use next version` to the Cassandra line and the hook stripped it on
the next run.
Extending that scan to the root `pyproject.toml` and having the generator
preserve the comment looks like it would close the gap and make exactly the
change you asked for possible. Happy to open a tracking issue for it, or pick
it up as a follow-up, if that reading seems right to you.
Until then the floor has to follow the release rather than lead it. #62924
took the same route when it dropped the `python_version != "3.13"` guard from
the FAB extras and left `>=2.2.0` in place.
That does leave the gap you identified: until the wave ships, a 3.14 install
resolves back to 3.9.2, the newest release predating the exclusion. If you'd
rather not carry it, I'm happy to cut this as Vespa-only and bring Cassandra
back once the provider is on PyPI with 3.14 support — Vespa needs nothing
either way, since no release excluding 3.14 was ever published for it.
Otherwise this is ready as it stands.
---
Drafted-by: Claude Code (Opus 5); reviewed by @Dev-iL before posting
--
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
To unsubscribe, e-mail: [email protected]
For queries about this service, please contact Infrastructure at:
[email protected]
