`uv pip compile --generate-hashes` makes it difficult to find meaningful changes when examining git commits

[neilmehta24]

The shasums are of course valuable, especially when using local wheels. But it's very difficult so compare version changes in Github because so much of the diff is dedicated to shasum changes. It would be nice if there was an easier way to compare what is changing when looking at a commit

[ncoghlan]

The first possibility that comes to mind is to have the locking process generate a versions-*.txt file alongside each locked requirements file.

The requirements file diffs would still be massive, but the version file diffs would just have a single line per package and hence be much easier to review.

[ncoghlan]

One aspect I realised this won't help with is making it clear when reviewing an upper layer diff which changes are to packages in that layer, and which changes are to packages in lower layers.

I'm not sure that one is particularly feasible to resolve without bypassing a lot of the standard tooling around Python packaging, though (whereas the version summary files can be built via a text transform of the full requirements files).

[ncoghlan]

While working on this, I decided "package summary" files would be a better name for this feature. "versions" already has too many other uses (outside package versions, there is also both explicit and implicit layer versioning)

[neilmehta24]

One aspect I realised this won't help with is making it clear when reviewing an upper layer diff which changes are to packages in that layer, and which changes are to packages in lower layers.

I think this is fine for now, we can always revisit if this proves to be a substantial issue

[ncoghlan]

As it turned out, my initial impression was overly pessimistic - at the point where the summary is generated, we have access to the full requirements of all the lower layers as well as those for the current layer. This means it is actually straightforward to split the requirements for the current layer based on whether or not they're listed in the lower layer requirements, and write those out as two separate sections in the summary file.

[ncoghlan]

Example summary file from the PR:

# Package summary for framework-http-client
#     Auto-generated by venvstacks (DO NOT EDIT)
anyio==4.6.2.post1
certifi==2024.8.30
h11==0.14.0
httpcore==1.0.6
httpx==0.27.2
idna==3.10
sniffio==1.3.1

# Shared packages inherited from other layers
numpy==2.1.2

First section may be empty if there are no packages directly installed (most likely for runtime layers and app layers that are just a launch module), second section is omitted entirely if nothing is inherited from a lower layer (most likely for runtime layers and framework layers that depend on them directly)