Good idea to test it on the tooling that everyone developing Airflow uses on a regular basis.
Thanks for making those changes, Jarek. Thanks & Regards, Amogh Desai On Mon, Oct 20, 2025 at 2:09 PM Jarek Potiuk <[email protected]> wrote: > Hello here, > > TL;DR; Please take a close look at `breeze` dependencies / uv.lock > accidental modifications that might happen and report any issues in > #airflow-breeze channel in slack if you see something strange. > > As part of the simplification and standardisation of our dev tooling I > merged a change https://github.com/apache/airflow/pull/56844 which builds > on uv, uv.lock for breeze to make sure everyone has the same versions and > so that they do not have to upgrade breeze when new deps are added or where > we bump dependencies due to security etc. > > So far we had some custom code that used pre-commit and package README > (really a small hack I implemented) which caused automated reinstalling of > breeze installed via `uv tool -e ./dev/breeze` when dependencies changed. > > This PR does basically the same but with using `uv.lock` and `uv tool > upgrade` automatically whenever you start `breeze` (uv is so fast that we > can easily afford running it every time you start `breeze`). > > It also uses `uv.lock` under the hood that is committed to the repository > and as discussed before, I wanted to use the uv.lock mechanism for our > monorepo to generate constraints. I want to test how it behaves for regular > usage and whether there are any surprises. Particularly I am not 100% sure > what will happen with the uv.lock and whether people will semi-randomly get > changes to it when dependencies get released. > > I want to do it as a test playground for the "monorepo" move. > > So If you see any strange things happening in breeze - please shout and tag > me in #airflow-breeze > > J. >
