Summarising where we are: After ~24 hrs of operations, it looks really cool and fulfills (and actually exceeds) all my expectations.
* Multiple PRs succeeded, we got quite a few constraints updated automatically after successful canary runs: https://github.com/apache/airflow/commits/constraints-main/ (and they look perfectly fine - pretty much what I'd expect) * I looked through a number of image builds in "canary" runs and the regular 10-12 minutes build-image jobs are down to 3-4 minutes * I just did an experiment and on my machine I run a complete from the scratch CI image with new dependencies build for breeze (with `breeze ci image build --python 3.9 --docker-cache disabled --upgrade-to-newer-dependencies` ) and compared it with v2-8-test branch where we do not have the change applied yet Results (on my desktop machine (16 cores, network 1Gb download and very fast disk): * v2-8-test: 730 s -> *12 minutes * * main: 227 s -> less than *4 minutes (!)* That's 70% (!) faster. This is a complete full rebuild of the image, including installing all dependencies from the scratch and attempting to upgrade them to the latest compatible versions. That is the WORST case. Of course it will vary - depending on the network speed you have and number of CPU (unlike `pip` for now `uv` heavily uses parallelism - both for downloads and installation and that is one of the reasons why the difference is so huge). I'd love to hear the results of such comparisons from others with different machines/networking/disks - to get a bit more scientific data points. It also means that if you've been using breeze and were sometimes afraid to hit "y" to rebuild the image, being afraid that it will take 20 minutes or so - not any more. It should be WAY faster now. I will also proceed to attempt to use the `--resolution lowest` soon and try to see if we can have a nice automation in place to bump our min-versions to the "actually working" versions - for all our extras. That would be a major win for our users - as there will never be a case in the future that they upgrade airflow to a newer version and some old dependency remains and is not compatible. It does not happen often, Seeing the speed difference - I am actually going now to regularly use `uv pip` for any local installation as well - it should save a LOT of time - especially that if you have multiple environments, it keeps a single cache for all your installed packages (and their metadata) - this means that if you have several virtualenvs installed and switch between them, the installation and reinstallation of packages between those packages should be lightning fast (like single seconds rather than 10s of seconds for smallest installation). I'd heartily recommend it to anyone. Let's see about the stability. I know there are few edge-cases that are not handled well - Damian helpfully pointed out to the "apache-airflow[all]" case that currently is problematic, so I will keep an eye on new versions and fixes (In CI of ours we are currently pinned to 0.1.10 - so we are shielded from any potential stability problems and we will need to manually upgrade to newer versions when they appear). J.
