That is a good point. For now "upgrade-important-versions" will run automatically in main, as it did before—when we receive a notification in the #internal-airflow-ci-cd channel. The current minimum upgrade frequency is set for four days. This means we can run it manually, but if the CI detects an upgrade is needed it will start failing the upgrade job in canary 4 days after the last upgrade. Someone watching the channel will then have to intervene and run it. Also that will happen automatically every time someone makes a change that will cause conflict with the current uv.lock.
This change is not backported to v3-1-test, so it does not affect v3.1.* releases, but yes - we need to add a step to run it manually for the 3.2 branch (for Airflow releases). Let me add that step to release process :) J. On Mon, Mar 16, 2026 at 5:30 AM Rahul Vats <[email protected]> wrote: > > Hi Jarek, > > Nice, thanks for getting this merged! > > The reproducibility improvement is actually useful for my workflow. I do a > fair bit of local migration stress testing and the environment drift > between local and CI has been quite annoying. Good to know uv sync will now > just give you the same thing. > One thing from the cons section you mentioned earlier, is there a plan to > document the upgrade-important-versions step as part of the release > procedure? You mentioned release managers would need to consciously run it > so would be good to have that captured somewhere so it doesn't get missed. > > Regards, > Rahul Vats > > On Sun, 15 Mar 2026 at 21:05, Jarek Potiuk <[email protected]> wrote: > > > Hello here, > > > > I've just merged https://github.com/apache/airflow/pull/63609, which > > implements committing and using uv.lock in Airflow. > > > > This **might** cause some issues when you are rebasing or switching > > branches because you might have uv.lock generated by your `uv sync` locally > > and it will **conflict** with the one coming from main of Airlfow. > > > > If you see conflict with `uv.lock` - just delete your local uv.lock file > > and try it again. That should solve the issue. > > > > What is the result of the change? > > > > * Anyone who checks out a specific commit in the future will have > > **exactly** the same uv.lock file used in this commit > > * This means that your local venv after `uv sync`, should normally have > > exactly the same version of dependencies as the corresponding CI image > > * This means that we should have better reproducibility between local venv > > tests and tests run in breeze/CI > > * If you change any dependencies in your PR it **might** (if there is a > > conflict) result with conflicting lock files. In such case just `uv sync` - > > should solve the issue (your lock file should be modified and you should > > commit it as part of your change > > * Some commits (particularly "upgrade important versions" ones - will have > > uv.lock changes (usually pretty big) which will periodically sync things up > > > > We should also see how it works out - it's been tested to an extent in > > breeze for quite a while so .... Let's see how it will work. > > > > > > Ping me at #conteibutors in case you have any problems. > > > > BTW. Agents should cope with it easily :) > > > > > > J. > > > > > > > > > > On Tue, Aug 19, 2025 at 11:04 PM Pavankumar Gopidesu < > > [email protected]> wrote: > > > > > > Thanks Jarek, that all makes sense :) Looking forward to it. happy to > > help > > > where I can. > > > > > > Pavan > > > > > > On Tue, Aug 19, 2025 at 9:56 PM Jarek Potiuk <[email protected]> wrote: > > > > > > > > > > > > > > > > > > > > > > > (1) If we plan to split the distributions to separate api-server, > > > > > scheduler deployments in future - will we then also as next increment > > > > > the split into multiple logical uv.locks? Or will it be (for the time > > > > > being) keep a gloabal uv-lock for all and everything in the repo? > > > > > > > > > > > > > This should be for sure one workspace and one uv.lock. The main > > > > reason (and the best feature of workspace) is that it puts all the > > > > distributions we have and figure out a set of dependencies that are > > > > not conflicting for ALL of them. This means that we will never get > > > > into the situation that we cannot install them all together - and > > despite > > > > of splitting the distributions we still want to be able to do > > > > > > > > pip install apache-airflow[all] > > > > > > > > And have everything installed in CI image. > > > > > > > > However, we might indeed decide to keep several uv.lock files (for > > > > example breeze has its own uv.lock file and it **works** - but it is > > > > mostly for testing). We could also have a separate one for airflow-ctl > > > > But there is a limited use of that (not unless we have pylock.toml) > > > > to be honest and it is nice to have a single CI image where > > > > everything is installed in one env and we can run it all in the image. > > > > > > > > > > > > (2) I have a bit of worries if somebody in a PR adds a dependency and > > > > > the uv-lock is a brader upgrade - we need to ensure if uv-lock is > > > > > touched such PR needs to run all tests in all versions? > > > > > > > > > > > > > We can. We already do that in fact - currently when you modify any > > > > of the pyproject.toml files, selective checks already set the > > > > "upgrade-to-newer-dependencies" output, and it triggers all tests, all > > > > versions > > > > and we can update it to be a bit more selective and work out right > > > > selective checks here. > > > > > > > > > > > > > (3) is the uv.lock Python version dependent? Because we need to have > > a > > > > > lock file per Python version. > > > > > > > > > > > > > It contains all combinations of versions and architectures and > > potentially > > > > other parameters that can make different resolution works. > > > > > > > > > > > > > > > > > > Other than this I hope that the change will be one that slims > > complexity > > > > > of dev tooling codebase with a minimal risk that we run into a > > uv-vendor > > > > > lock... but the way back is not blocked will just be effort if astral > > > > > turns into evil in the future. > > > > > > > > > > > > > Yeah. That is a valid worry. It only touches the development side for > > now > > > > and this makes it easy to revert. Honestly it does not lock us "too > > much". > > > > Constraints are generally generated from 'installed" packages (we do > > > > essentially `pip freeze` in ci-image (simplified - it's a bit more > > complex > > > > than that and we have 3 variants of those). Currently we already use > > > > a very long `uv pip install a b c d --constraint` (list of packages > > derived > > > > from > > > > list of pyproject.toml we have to get that environment and we could > > > > do it with `pip` (way slower but pip is implementing some of the > > speedups > > > > that uv already did). This change is going to replace it with - > > essentially > > > > `uv sync --frozen --all-packages` . And we have history of those > > > > changes so we can always go back. It would mean + few 100 > > > > lines of code or so, but nothing major. > > > > > > > > > > > > > > > > > > Jens > > > > > > > > > > On 19.08.25 16:12, Jarek Potiuk wrote: > > > > > > Yeah. Dependabot has support for it and I am already testing it for > > a > > > > > while > > > > > > with breeze's `uv.lock` - so - to add a bit of context - I started > > slow > > > > > by > > > > > > commitiung `uv.lock` in breeze and seeing the kind of issues we > > might > > > > > have. > > > > > > One of the issues there is that I am not entirely sure if we want > > > > > > dependabot to upgrade things for us for the whole "workspace", I > > find > > > > > this > > > > > > auto-upgrade that is happening currently way better - because it > > > > > literally > > > > > > gets us few hours feedback when things are broken by packages > > released > > > > by > > > > > > 3rd-parties - and we know when they break our tests, otherwise it's > > > > > pretty > > > > > > transparent. > > > > > > > > > > > > If you look at our constraints history > > > > > > https://github.com/apache/airflow/commits/constraints-main/ we > > have > > > > 3-4 > > > > > > constraints upgrades a DAY(!) and many of those upgrades are more > > than > > > > > one > > > > > > dependency. And this is really nice because those are literally > > > > > > "checkpoints" of "dependencies we knew passed all the tests". So > > when > > > > > > someone releases a dependency that breaks something we do not need > > to > > > > > look > > > > > > far - our "canary" build shows exactly what's changed since the > > last > > > > > "good > > > > > > canary run" - which means that we can identify and fix the problems > > > > super > > > > > > quickly - because we know that this particular dependency upgrade > > > > caused > > > > > > it. And it's super easy to test with breeze - you just reproduce it > > > > > > failing, downgrade the dep and see it working - and you know 100% > > > > that's > > > > > it. > > > > > > > > > > > > This follows one of my favourite saying - "if something is painful, > > do > > > > it > > > > > > more often" - this is why resurrecting and old branch (I am > > dreading a > > > > > bit > > > > > > the moment I will start preparing 2.11.1) is often quite painful - > > > > > because > > > > > > you see many things broken and you have to track it through 100s of > > > > > > dependencies upgraded. > > > > > > > > > > > > Current way Dependabot works will not give us the same experience > > > > though > > > > > - > > > > > > it's either going to be very annoying (with dependabot PR upgrade > > every > > > > > > single day at the very least) - or causing longer investigations > > (if we > > > > > > batch it for - say - weekly upgrades). None of those two is even > > close > > > > to > > > > > > the current experience with constraints where things **just work** > > - > > > > > until > > > > > > they don't and then you know what to do. > > > > > > > > > > > > So what's I am aiming at in this "uv.lock" change is not even to > > use > > > > > > dependabot for it, but to fulfill those two seemingly contradictory > > > > > goals: > > > > > > > > > > > > * keep the seamless experience of upgrades in "canary" and allowing > > us > > > > to > > > > > > diagnose and fix failures quickly > > > > > > * but give even more stability and "standard" experience with `uv > > sync` > > > > > and > > > > > > `uv lock` features so that contributors and committers can get more > > > > > > "stable" and more "works for me syndrom free" experience. > > > > > > > > > > > > And I think what I proposed will allow us to eat cake and have it > > too - > > > > > > what I proposed (without even having dependabot involved) will > > actually > > > > > do > > > > > > the job quite nicely on both fronts. > > > > > > > > > > > > BTW. We will still likely use dependabot for airflow deps but > > **only** > > > > to > > > > > > address security needs I think. We are already on a streak to > > squash > > > > and > > > > > > remove all kinds of blockers to upgrade things, but having > > dependabot > > > > > flag > > > > > > it for us automatically would be quite nice. > > > > > > > > > > > > J. > > > > > > > > > > > > > > > > > > > > > > > > On Tue, Aug 19, 2025 at 2:48 PM Pavankumar Gopidesu < > > > > > [email protected]> > > > > > > wrote: > > > > > > > > > > > >> Thanks Jarek for bringing this up, I really like this idea we > > should > > > > use > > > > > >> uv.lock. > > > > > >> > > > > > >> For upgrading packages in the uv.lock file, dependaboat started > > adding > > > > > >> support for this, but it seems there are quite a lot of issues. > > > > > >> Some i have seen dependaboat updates lock file but not updating > > the > > > > > package > > > > > >> in toml file etc; there may be other issues similar to related. > > but I > > > > > hope > > > > > >> these may be addressed at some point of time ( Not sure when :) ) > > > > > >> > > > > > >> > > > > > > > https://docs.astral.sh/uv/guides/integration/dependency-bots/#dependabot > > > > > >> https://github.com/astral-sh/uv/issues/2512 > > > > > >> > > > > > >> > > > > > > > > > > > > > https://github.com/dependabot/dependabot-core/issues?q=is%3Aissue%20state%3Aopen%20uv > > > > > >> > > > > > >> Pavan > > > > > >> > > > > > >> On Tue, Aug 19, 2025 at 11:18 AM Wei Lee <[email protected]> > > wrote: > > > > > >> > > > > > >>>> pip is not aiming and > > > > > >>>> will likely never be a "development/project management" tool and > > > > > >>> I’m a bit surprised. I thought the dep group thing was for this. > > > > > >>> > > > > > >>>>> 3) to give our users a way to install released airflow in > > > > > reproducible > > > > > >>> way > > > > > >>> > > > > > >>>> be able to use `uv` export to pylock.toml and replace our > > > > > >> `--constraint` > > > > > >>>> installation. > > > > > >>> I’m thinking of supporting both. Or at least for a while, till > > > > > >>> `pylock.toml` becomes well-known (which might take a long long > > time…) > > > > > >>> They’re generated files, so might not be that hard to maintain. > > > > > >>> > > > > > >>> > > > > > >>> Best, > > > > > >>> Wei > > > > > >>> > > > > > >>>> On Aug 19, 2025, at 5:45 PM, Jarek Potiuk <[email protected]> > > wrote: > > > > > >>>> > > > > > >>>>> +1 to this idea. I considered whether we should use > > `pylock.toml` > > > > > >>>> instead, but it might not address the issue we intend to resolve > > > > based > > > > > >> on > > > > > >>>> my reading. > > > > > >>>> > > > > > >>>> Yeah. pylock.toml and https://peps.python.org/pep-0751/ (in the > > > > > >> future) > > > > > >>> are > > > > > >>>> better replacement for point 3: > > > > > >>>> > > > > > >>>>> 3) to give our users a way to install released airflow in > > > > > reproducible > > > > > >>> way > > > > > >>>> This is the intention of pylock.toml - it should eventually > > allow > > > > our > > > > > >>> users > > > > > >>>> to install airflow in a reproducible way so basically would > > replace > > > > > the > > > > > >>>> constraints of ours. For now support for it is experimental in > > PyPI > > > > > and > > > > > >>> it > > > > > >>>> might change, also there is a general consensus that it does not > > > > fully > > > > > >>>> replace the ".lock" files feature for poetry, uv, pip-tools when > > it > > > > > >> comes > > > > > >>>> to local development, workspaces, monorepos (which don't even > > have > > > > > >>>> standardisation yet). Also `uv` supports PEP751 pylock.toml as a > > > > > >> (loosy - > > > > > >>>> it removes a number of metada kept in uv.lock specific for > > > > development > > > > > >>>> workflows) export format from its uv.lock. > > > > > >>>> > > > > > >>>> My view (and also a lot of the information I got from packaging > > > > people > > > > > >> i > > > > > >>>> interact with) - that each of the "development/project > > management" > > > > > >> tools > > > > > >>>> (like uv/poetry etc.) will keep their own ".lock" format - > > simply > > > > > >> because > > > > > >>>> there is no possible way to encompass all the needs they have in > > > > > >> "generic > > > > > >>>> way". There was about 100 os pages discussion when PEP 751 was > > > > > proposed > > > > > >>> and > > > > > >>>> uv team took a very active part in it - but there seem to be a > > > > number > > > > > >> of > > > > > >>>> points that are not really "generic". For example pip is not > > aiming > > > > > and > > > > > >>>> will likely never be a "development/project management" tool and > > it > > > > > >> does > > > > > >>>> not have a "workspace project" - it will always be really > > "end-user > > > > > >>>> installatiion tool" as it's primary function - and the result of > > > > this > > > > > >>>> different approach is what PEP 751 aims for - to allow > > reproducible > > > > > >>>> installation for end users. > > > > > >>>> > > > > > >>>> So what I see as a natural step when we adopt `uv.lock` as > > > > development > > > > > >>>> "source of truth" and our "development/project management tool" > > - we > > > > > >> will > > > > > >>>> be able to use `uv` export to pylock.toml and replace our > > > > > >> `--constraint` > > > > > >>>> installation. But while several tools (both pip and uv) already > > > > > support > > > > > >>>> exporting to the pylock.toml, there is no way YET to install > > > > packages > > > > > >>> using > > > > > >>>> such lock to actually install packages. Pip for example has this > > > > issue > > > > > >>> open > > > > > >>>> for it https://github.com/pypa/pip/issues/13334 and it waits > > for > > > > > >>> someone > > > > > >>>> to volunteer and implement it. So for us it would make sense to > > > > switch > > > > > >>> for > > > > > >>>> 3) from constraints to pylock.toml - but only after `pip` and > > other > > > > > way > > > > > >>>> people install airflow will be able to use it. Before that - > > there > > > > is > > > > > >> no > > > > > >>>> benefit of us using it. This might even stay like that: > > `uv.lock` > > > > for > > > > > >>>> development and pylock.toml published by us for users who want > > to > > > > > >> install > > > > > >>>> airflow in reproducible way. The `pylock.toml` has a number of > > > > > benefits > > > > > >>>> comparing to current constraint approach - single lock > > supporting > > > > > >>> multiple > > > > > >>>> python versions, cryptographic integrity and attestation > > support, > > > > > >> support > > > > > >>>> for multiple platforms, support for dependency groups, support > > for > > > > > >>> default > > > > > >>>> groups - all that will make few of our "custom" mechanisms we > > > > > >> currently > > > > > >>>> "workaround" into the "solid features" of reproducible > > installation. > > > > > >> But > > > > > >>> we > > > > > >>>> are not there yet :).\ > > > > > >>>> > > > > > >>>> J. > > > > > >>>> > > > > > >>>> > > > > > >>>> On Tue, Aug 19, 2025 at 10:59 AM Wei Lee <[email protected]> > > > > wrote: > > > > > >>>> > > > > > >>>>> +1 to this idea. I considered whether we should use > > `pylock.toml` > > > > > >>> instead, > > > > > >>>>> but it might not address the issue we intend to resolve based > > on my > > > > > >>> reading. > > > > > >>>>> Best, > > > > > >>>>> Wei > > > > > >>>>> > > > > > >>>>>> On Aug 19, 2025, at 5:51 AM, Ferruzzi, Dennis > > > > > >>>>> <[email protected]> wrote: > > > > > >>>>>> I don't have any particular experience, but based just on what > > you > > > > > >>>>> shared there, it does feel like a next logical step in the > > > > migration > > > > > >> to > > > > > >>>>> these tools. Off-loading work and simplifying our CI is also > > > > always > > > > > a > > > > > >>> plus > > > > > >>>>> in my opinion. > > > > > >>>>>> > > > > > >>>>>> - ferruzzi > > > > > >>>>>> > > > > > >>>>>> > > > > > >>>>>> ________________________________ > > > > > >>>>>> From: Jarek Potiuk <[email protected]> > > > > > >>>>>> Sent: Monday, August 18, 2025 4:14 AM > > > > > >>>>>> To: [email protected] > > > > > >>>>>> Subject: [EXT] [DISCUSS] Replace constraints with uv.lock > > > > mechanisms > > > > > >>> for > > > > > >>>>> dev env freeze > > > > > >>>>>> CAUTION: This email originated from outside of the > > organization. > > > > Do > > > > > >> not > > > > > >>>>> click links or open attachments unless you can confirm the > > sender > > > > and > > > > > >>> know > > > > > >>>>> the content is safe. > > > > > >>>>>> > > > > > >>>>>> > > > > > >>>>>> AVERTISSEMENT: Ce courrier électronique provient d’un > > expéditeur > > > > > >>>>> externe. Ne cliquez sur aucun lien et n’ouvrez aucune pièce > > jointe > > > > si > > > > > >>> vous > > > > > >>>>> ne pouvez pas confirmer l’identité de l’expéditeur et si vous > > > > n’êtes > > > > > >> pas > > > > > >>>>> certain que le contenu ne présente aucun risque. > > > > > >>>>>> > > > > > >>>>>> > > > > > >>>>>> Hello here, > > > > > >>>>>> > > > > > >>>>>> *TL;DR: I would love to hear comments on the proposal to > > switch to > > > > > >>> using > > > > > >>>>>> uv.lock for our dev env dependency freeze* > > > > > >>>>>> > > > > > >>>>>> While working on some small follow-ups after prek upgrade, I > > > > think I > > > > > >>>>>> finally figured out how we can start using `uv.lock` locally > > and > > > > > >> merge > > > > > >>> it > > > > > >>>>>> into our constraint mechanism effectively - without > > > > > >>>>>> over-burdening committers with merging a lot of > > "dependabot-like" > > > > > >> PRs. > > > > > >>>>>> The key problem that needed to be resolved was who and when > > would > > > > > >>> update > > > > > >>>>>> the uv.lock regularly. > > > > > >>>>>> > > > > > >>>>>> I captured my thoughts in > > > > > >>> https://github.com/apache/airflow/issues/54609 > > > > > >>>>>> But let me copy the content of it below. I would love to hear > > the > > > > > >>>>> comments > > > > > >>>>>> - here or in the GitHub issue if you will (I will bring > > important > > > > > >>> things > > > > > >>>>>> from the issue here if they will be raised there): > > > > > >>>>>> > > > > > >>>>>> > > > > > >>>>>> *Currently constraints are used for three purposes:* > > > > > >>>>>> 1) to take snapshot of latest "working" version of > > dependencies > > > > > >>>>>> 2) to limit PRs to "latest known good constraints" - so that > > newly > > > > > >>>>> released > > > > > >>>>>> packages are not failing most PRs, but fail canary builds > > instead > > > > > >>>>>> 3) to give our users a way to install released airflow in > > > > > >> reproducible > > > > > >>>>> way > > > > > >>>>>> However, after we switched to uv, the case 2) can be better > > > > achieved > > > > > >>> with > > > > > >>>>>> uv.lock. Currently we .gitignore uv.lock, but we could commit > > it > > > > to > > > > > >> the > > > > > >>>>>> repository and handle constraint generation differently > > > > > >>>>>> > > > > > >>>>>> * constraints could be generated using latest lock > > > > > >>>>>> * canary builds could use the --resolution highest as today > > and > > > > > >> diverge > > > > > >>>>>> from latest "frozen" uv.lock > > > > > >>>>>> * all prs would use the uv.lock and do not use > > > > --resolution-highest > > > > > >> in > > > > > >>>>>> those PRs. This has the added benefit that uv sync in PR would > > > > > >>>>>> automatically upgrade dependencies if the dependencies in > > > > > >>> pyproject.toml > > > > > >>>>>> are conflicting with uv.lock - but it would not use > > --resolution > > > > > >>> highest, > > > > > >>>>>> which means that the PRs that modify dependeNcies do not have > > to > > > > get > > > > > >>>>> latest > > > > > >>>>>> dependencies when they are run - that would limit the number > > of > > > > PRs > > > > > >>> that > > > > > >>>>>> are experiencing "main/canary" problems > > > > > >>>>>> > > > > > >>>>>> *Problem* > > > > > >>>>>> > > > > > >>>>>> The only problem to solve is who and when would upgrade the > > > > uv.lock > > > > > >> and > > > > > >>>>>> commit it to the repo. Currently constraints are automatically > > > > > bumped > > > > > >>>>> after > > > > > >>>>>> successful canary runs, but they are in orphan un-protected > > > > > branches, > > > > > >>>>> while > > > > > >>>>>> uv.lock shares the code with main airflow repo, and we need a > > > > "human > > > > > >>> with > > > > > >>>>>> ICLA" to review and merge commits there (ASF requirement) > > > > > >>>>>> > > > > > >>>>>> > > > > > >>>>>> *Solution* > > > > > >>>>>> Proposed solution is to add such a uv.lock upgrade to our > > > > > >>>>>> "upgrade-important-versions" prek hook. We run it in CI in > > canary > > > > > >>> builds > > > > > >>>>>> and we fail the builds when new versions of important > > installers > > > > > >> change > > > > > >>>>>> (pip, Python base images, golang) - this happens often-enough > > to > > > > be > > > > > >>>>>> eventually-consistent pretty fast, but rarely enough to make > > it > > > > into > > > > > >>>>>> annoying "everyday" upgrade chore. > > > > > >>>>>> > > > > > >>>>>> Regular PRs - especially those that would change dependencies > > will > > > > > >> also > > > > > >>>>>> modify uv.lock - for example when a new dependency is added or > > > > > >> removed > > > > > >>> or > > > > > >>>>>> bumped. This means that the uv.lock will be generally quite > > > > > regularly > > > > > >>>>>> bumped and "eventually consistent" with constraints. > > > > > >>>>>> > > > > > >>>>>> > > > > > >>>>>> *Benefits:* > > > > > >>>>>> * simplification of breeze build image with constraints > > (currently > > > > > it > > > > > >>>>> uses > > > > > >>>>>> complex uv pip install with --constraint, and it could simply > > use > > > > uv > > > > > >>> sync > > > > > >>>>>> --all-packages instead if our uv.lock is checked in and > > maintained > > > > > >>>>>> * better synchronization of the local venv. Currently uv sync > > does > > > > > >> not > > > > > >>>>>> guarantee to have the same version of dependencies in local > > venv. > > > > > The > > > > > >>>>> only > > > > > >>>>>> way to guarantee it now is to use breeze image - build with > > > > > >> constraints > > > > > >>>>> or > > > > > >>>>>> run complex commands with constraints added when you run uv > > sync > > > > > >>>>>> * less "3rd-party release" impact on failing PRs. if PRs will > > not > > > > > >> touch > > > > > >>>>> the > > > > > >>>>>> dependency specification where the new release is released, it > > > > will > > > > > >>>>>> continue using the dependency stored in .lock and not the > > latest > > > > > >>>>> dependency > > > > > >>>>>> released > > > > > >>>>>> > > > > > >>>>>> > > > > > >>>>>> *Cons:* > > > > > >>>>>> * Probably we should pay more attention to run > > > > > >>> upgrade-important-versions > > > > > >>>>>> regularly and even add an option there to manually just > > perform > > > > the > > > > > >>> sync > > > > > >>>>>> (for example that will be useful as part of the release > > procedure, > > > > > >>> where > > > > > >>>>>> release manager would have to make sure to run the > > > > > >>>>>> upgrade-important-versions check when preparing release notes. > > But > > > > > it > > > > > >>> has > > > > > >>>>>> the advantage that it will be a conscious step that should > > > > actually > > > > > >>> help > > > > > >>>>> in > > > > > >>>>>> making sure that constraints are updated. > > > > > >>>>>> > > > > > >>>>>> * sometimes PRs of people will have "big" changes to uv.lock - > > > > when > > > > > >>> they > > > > > >>>>>> are updating the dependency and alongside the uv.lock will > > also > > > > bump > > > > > >>> many > > > > > >>>>>> other unrelated dependencies - this could be mitigated by > > > > splitting > > > > > >> it > > > > > >>>>> into > > > > > >>>>>> "lock upgrade" and "dependency update" but workflow of that is > > not > > > > > >> very > > > > > >>>>>> convenient and natural. > > > > > >>>>>> > > > > > >>>>>> J. > > > > > >>>>> > > > > > >>>>> > > > > --------------------------------------------------------------------- > > > > > >>>>> To unsubscribe, e-mail: [email protected] > > > > > >>>>> For additional commands, e-mail: [email protected] > > > > > >>>>> > > > > > >>>>> > > > > > >>> > > > > > >>> > > --------------------------------------------------------------------- > > > > > >>> To unsubscribe, e-mail: [email protected] > > > > > >>> For additional commands, e-mail: [email protected] > > > > > >>> > > > > > >>> > > > > > > > > > > --------------------------------------------------------------------- > > > > > To unsubscribe, e-mail: [email protected] > > > > > For additional commands, e-mail: [email protected] > > > > > > > > > > > > > > > > --------------------------------------------------------------------- To unsubscribe, e-mail: [email protected] For additional commands, e-mail: [email protected]
