Hello here, *TL;DR; Following the discussion https://lists.apache.org/thread/88yj3qxqdmc4ony7k8nvp292m28df31c <https://lists.apache.org/thread/88yj3qxqdmc4ony7k8nvp292m28df31c> I am calling for a lazy consensus on using only `uv` for local development of Airlfow. *
This adds a bit of reliance on a VC-backed astral-owned (but fully open-sourced) `uv` which has some risks, but we think the risks are small. It's only for airflow development - we will leave constraint mechanism for our users, so that their workflows will not require to change the frontend they use to install airflow (both `pip` and `uv` supporting our constraints, `poetry` and others installing airflow without constraints and having to manage their own limits - that does not change) A bit more context and summary of the discussion follows. I also have a half-ready change that performs all the removals and I have a bit more info on what's going to happen when we go `uv only. --------- More context: Here is what we will get if go `uv` only: Good: * currently we support `uv` and `pip` (or more generally "any PEP-standard frontend) workflows * however, some uv features (particularly `workspaces` and `uv.lock`) that are not yet standard, make the development workflows of ours very easy to follow (AKA uv provides much better "Contributor journey optimisation") * by focusing on "one way to do things" with uv we will be able to simplify a lot of contributor experience but also a lot of our packaging code and configuration: - we will be able to get rid of the dynamic pyproject.toml dependencies around preinstalled providers - we will be able to get rid of hatch_build.py in the main repo completely - we will only leave `hatch_build.py` in the "airflow-core" for custom build step compiling assets and performing git version injection (but this is purely optional and used only when releases are prepared) - we will be able to get rid of generated_provider_dependencies.json prepared by pre-commit - it was needed for hatch_build.py mainly and we can replace its use completely by directly reading pyproject.toml files in pre-commit and build scripts. - that in turn will enable us (eventually - that is another change) to switch to dependabot-only driven process of upgrading our dependencies and use `uv.lock` for local development and avoiding "works for me" syndrome - this will make it more controllable when things are going to break main and our "responses" will based on Dependabot PRs rather than notification of canary build breaking, which will make it - I think much easier to handle. * uv is true open-source - i.e. OSI-compliant licences (uv is dual-licenced with Apache 2 and MIT) Somewhat concerning (but acceptable risk it seems): * Those features we rely on are `uv-only` for now. The uv team is committed to support standards and actively participate in all the PEP packaging discussions - including reproducible installation, dependency groups and others (workspaces in the future most likely) - which means that in the future other tools will catch up and we will be able to follow standards when they are approved and implemented. * unlike other packaging tools (under Python Software Foundation - Python Packaging Governance) - `uv` is privately owned, by VC-backed Astral. They are great open-source stakeholders and understand the value of `uv` being open-source and we personally know the team and they have very good intentions, no doubt about it. But as various events have shown in the past - change-of-control events might influence "openness", so we cannot be sure what the future brings. * However, being "true OSS" - `uv` can be forked by anyone if anything bad happens. Also it does not impact our users - just contributing workflow, so the risks are small and mitigable (like freezing tooling and working on a solution in the meantime). J.
