GitHub user salimuddin07 deleted a comment on the discussion: Airflow Constraints vs FAB providers pyproject
This issue comes down to a mismatch between Airflow’s global constraints and the FAB provider’s declared dependencies. The FAB provider says it supports `werkzeug>=2.2,<4,` which is why Chainguard includes Werkzeug 3.1.3. But in practice, Airflow pins Werkzeug to 2.2.3 in its constraints, because of indirect dependencies like `connexion[flask]`. That pinning avoids breakages like the LDAP error you hit — since the FAB provider still has code paths that aren’t compatible with newer Werkzeug releases (e.g., importing` __version__ `directly). So, what you’re seeing is expected for now: If you follow Airflow’s official constraints file, everything works (your fix). If you follow only the FAB provider’s looser requirements, you can hit runtime errors with newer Werkzeug versions. The maintainers confirmed that: connexion is still used inside FAB for its API endpoints, so the lower Werkzeug constraint is not accidental. A patch to clean up imports and improve compatibility with newer Werkzeug is welcome. Once that lands, constraints can probably be relaxed. Recommended path forward for you right now: Stick to the Airflow constraints file for your environment — this guarantees tested compatibility. If you need Chainguard images, you may have to override their Werkzeug version down to match Airflow’s constraints until upstream fixes are merged. Keep an eye on the FAB provider’s repo — a patch is in the works to make the provider compatible with Werkzeug 3.x. GitHub link: https://github.com/apache/airflow/discussions/55456#discussioncomment-14582465 ---- This is an automatically sent email for [email protected]. To unsubscribe, please send an email to: [email protected]
