feat: Make use of the `uv.lock` file

[johnslavik]

In bf3c328, uv.lock was added to the .gitignore template.

I'd like to propose we always store the lock file in the repo.

In griffe, I was scratching my head figuring out why CI shows no mypy errors while my fresh installation of the project reported a number of them. Only then did I run make allrun uv sync --upgrade && make allrun check-types and saw it pass. The upgrade bumped my mypy version. A lockfile would eliminate that scenario in the first place and be a source of truth regarding what versions of tools are used by everybody.

Having a lockfile will work with our tests against different resolutions and even potentially speed up CI by not re-resolving already resolved deps. Of course, uv sync will ignore the lockfile when explicitly given a different resolution than the one used to produce the lockfile, showing a message like

Ignoring existing lockfile due to change in resolution mode: `highest` vs. `lowest-direct`

As a bonus, we may want to set --exclude-newer in sync in CI to the datetime of the examined git revision to fully make sure the runs are roughly reproducible at all times. But we'd still want to see CI without --exclude-newer to catch stuff.

[pawamoy]

Thanks for the suggestion. Unfortunately I really, really dislike tracking lock files. I'm all for making CI a bit more... reproducible? Reliable? But really not a fan a tracked lock files and all the noise that come with them. Happy to be convinced otherwise 🙂

[johnslavik]

Thanks! That makes sense. What exactly do you not like about tracking lock files? The diffs or keeping them up-to-date in the repo?

[pawamoy]

The diffs, having to think about keeping them up-to-date, the merge conflicts, the associated dependabot/renovatebot PRs, having to be careful not to commit modifications to it when playing with other versions/resolutions.

[johnslavik]

The diffs

Well, they're collapsed in GitHub. And I think we could technically mark the file as binary...

having to think about keeping them up-to-date

We could have a prek or pre-commit hook. It works really well. But I know that it creates more problems than solves at times. So we can just have a CI check that lets us know if we're cooked.

the merge conflicts

The common case is when you change dependencies both on main and on topic branch after branching off... Anything else? I think it's rare enough to not be huge pain.

the associated dependabot/renovatebot PRs

Do we have dependabot/renovatebot enabled though?

having to be careful not to commit modifications to it when playing with other versions/resolutions.

Well, I guess that that's not something specific to uv.lock only :P

Overall, I think the benefit is quite significant. I'm leaving it to you to decide whether we want to try and give uv.lock a shot :) Maybe it's not going to be that bad in practice.

[pawamoy]

Well, they're collapsed in GitHub

That's not the only place we look at diffs.

And I think we could technically mark the file as binary...

Sounds like a hack. We'd use .gitattributes or something? What if we then actually want to see the diff?

We could have a prek or pre-commit hook.

I know I'm very opinionated, but I also dislike pre-commit. I've heard good things about prek, notably that it's much faster, which is good, but the principle stays the same 🤔 I'd have to experiment with prek before deciding about it.

The common case is when you change dependencies both on main and on topic branch after branching off... Anything else? I think it's rare enough to not be huge pain.

The other case is when you forgot to restore uv.lock after updating your deps and you commit it.

Do we have dependabot/renovatebot enabled though?

No, but that's generally what follows when projects start tracking their lock files. "Huh it's cumbersome to keep up-to-date, lets automate that".

Well, I guess that that's not something specific to uv.lock only :P

It's not indeed!

Overall, I think the benefit is quite significant.

I'd like you to state the benefit one more time please 😁 Because IMO it doesn't outweigh the cons.

I'm happy to improve the DX though, with something like a make upgrade command that force-upgrades all dependencies in all venvs or something. That would be our motto: "always be up-to-date" (and test on lowest-direct of course).

In griffe, I was scratching my head figuring out why CI shows no mypy errors while my fresh installation of the project reported a number of them.

I'll do note that in some cases, even after upgrading my dependencies locally, CI was still installing different ones (and I never figured out why, maybe a cache thing), so I guess a tracked locked file would have helped there. But it's been an extremely rare occurrence.

Maybe it's not going to be that bad in practice.

I accept that people enjoy this workflow, but having worked with tracked lock files in Copier, I really can't say that for myself. People often update the lock file and commit the changes as part of PRs, so now you have to ask them to revert, which isn't always straight-forward for inexperienced contributors, etc.

[johnslavik]

What about the recent 3-in-a-row supply chain attacks in npm that were spread by patch autoupgrades? :p

[pawamoy]

Yeah I suppose protecting ourselves (if not our users) is always a good thing. But then when updating the lock file we should only upgrade to versions released more than X weeks ago, to make sure any potential malicious version was already detected and removed from PyPI. uv can do that (just need to compute datetime.now() - timedelta(weeks=X)).

[johnslavik]

Seems like a reasonable heuristic!

[johnslavik]

I hope that it doesn't block a reverse problem, which is patches to accidentally breaking changes / security vulnerabilities.

[johnslavik]

But at the same time, this shouldn't be a thing if a problem is detected and addressed in X weeks.

[johnslavik]

I'd say: go for it and adapt as necessary. You?

[pawamoy]

Can we try it in Griffe first? Before generalizing it into the template.

[pawamoy]

Another thought: preventing to get releases from less than X weeks ago is cool, but is it possible to allowlist some of the dependencies? Typically, our own (other projects we maintain and just released). Otherwise this is going to be problematic. I don't think uv allows such fine-grain strategies for resolution.