Bump ruff to 0.12.8 everywhere

[potiuk]

Bump ruff to the new version, also remove ruff from task-sdk codegen because "dev" dependency group that is automatically used when uv sync is run for development contains "apache-airflow-devel-common" that already has the ruff dependency. Any discrepancy leads to conflict so likely better to depend on the ruff version from devel-common everywhere.

---

^ Add meaningful description above
Read the Pull Request Guidelines for more information.
In case of fundamental code changes, an Airflow Improvement Proposal (AIP) is needed.
In case of a new dependency, check compliance with the ASF 3rd Party License Policy.
In case of backwards incompatible changes please leave a note in a newsfragment file, named {pr_number}.significant.rst or {issue_number}.significant.rst, in airflow-core/newsfragments.

[potiuk]

BTW. WDYT @ashb @kaxil @amoghrajesh about moving the "generate_task_sdk_models.py" to dev inside "task-sdk" distriibution ?

I am working towards all distributions being really "standalone" i.e. except dependencies that are introduced by pyproject.toml (for example `dev = ["apache-airfow-devel-common"]" - I think our monorepo distributions should not depend on anything "outside" of their own folder structure:

That would also simplify the generation step. Instaed of:

uv run -p 3.12 -active --group codegen --project apache-airflow-task-sdk --directory task-sdk -s dev/generate_task_sdk_models.py

We could have:

cd task-sdk
uv run -p 3.12 --group codegen -s dev/generate_task_sdk_models.py

Because --project apache-airflow-task-sdk --directory task-sdk are implied if you are running the command from task-sdk dir - and it also has nice property that you can open "task-sdk" folder as a project in your IDE and only work on that project without seeing any of the other "airflow" code. This makes it "truly monorepo" in the sense that while the projects are in single big repo, you can work only on one project. That's the nice feature of having uv workspace

Do you think it's a good idea ?

[amoghrajesh]

@potiuk yes that is a good idea, and unless I am mistaken, it is already present in task-sdk/dev and uv run -p 3.12 --group codegen -s dev/generate_task_sdk_models.py after cd task-sdk already works?

[potiuk]

@potiuk yes that is a good idea, and unless I am mistaken, it is already present in task-sdk/dev and uv run -p 3.12 --group codegen -s dev/generate_task_sdk_models.py after cd task-sdk already works?

🤦 -> indeed the --directory task-sdk actually changes the dir automatically instead of manually cd'ing ...

Stupid me :)

[github-actions]

Backport failed to create: v3-0-test. View the failure log Run details

Status	Branch	Result
❌	v3-0-test

You can attempt to backport this manually by running:

cherry_picker 74bdd3a v3-0-test

This should apply the commit to the v3-0-test branch and leave the commit in conflict state marking
the files that need manual conflict resolution.

After you have resolved the conflicts, you can continue the backport process by running:

cherry_picker --continue