Dev-iL commented on code in PR #74696:
URL: https://github.com/apache/airflow/pull/74696#discussion_r4308480004
##########
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:
Took the second option for Cassandra in 9b4e0f7 — floor raised to the
release that will carry 3.14 support. Since the extras floors are generated, it
goes through `MIN_VERSION_OVERRIDE` in `update_airflow_pyproject_toml.py`
rather than a direct edit, and the PR carries `allow provider dependency bump`
to get past `check_provider_dependency_bumps`.
Two corrections to the failure mode while I was checking it:
**Cassandra doesn't fail to install — it quietly installs the wrong thing.**
`!=3.14.*` only appears from 3.9.3 onwards; 3.7.0 through 3.9.2 predate the
exclusion and still admit 3.14. So with `>=3.7.0` the resolver backtracks to
3.9.2 and succeeds, landing a provider cut long before anyone tested it on
3.14. Worse than a hard failure, since nothing surfaces it.
**Vespa doesn't need a floor at all.** Nothing excluding 3.14 was ever
published — 0.1.0 and 0.1.1 declare `requires-python >=3.10`, 0.1.2 declares
`>=3.11`, and all three depend on plain `pyvespa>=1.1.2`, which resolves to
1.2.9 on 3.14 because every earlier pyvespa caps at `<3.14`. #74559's exclusion
never made it to PyPI. So `apache-airflow[vespa]` already installs correctly on
3.14 and raising that floor would only force an upgrade on people it doesn't
help. Left it at `>=0.1.0`.
One assumption worth a second pair of eyes: I used 3.11.0, reading "adds a
Python version" as a feature-level change — that's how ydb, apache.kafka and
yandex numbered their 3.13 work, though apache.beam filed its under Misc and
took a patch bump. If the wave cuts this as 3.10.2 instead, the override needs
following down, and nothing in CI will catch it: `uv.lock` records the provider
as a workspace editable with no specifier, so the floor is never resolved
locally. Also worth noting the generator emits a single floor per provider, so
this moves 3.11-3.13 users onto the new release too, not just 3.14.
---
Drafted-by: Claude Code (Opus 5) (reviewed by #Dev-iL after 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]
