Implement --report for uv pip install

[edgarrmondragon]

From the pip docs:

The --report option of the pip install command produces a detailed JSON report of what it did install (or what it would have installed, if used with the --dry-run option).

This produces a nice JSON report that's essentially pip compile but with a different and more detailed output format.

Related

• Add --dry-run flag for pip install #1244

References:

• https://pip.pypa.io/en/stable/cli/pip_install/#obtaining-information-about-what-was-installed
• https://pip.pypa.io/en/stable/reference/installation-report/

[T-256]

related #411

[yajo]

Do we have any current workaround for this?

[sfc-gh-nsharma]

+1, this feature will be very useful for us for creating reproducible environments.

[charliermarsh]

Can you expand on the use-case? Why would this be an output of pip install rather than pip compile?

[sfc-gh-nsharma]

We are basically trying to get parity with https://pip.pypa.io/en/stable/cli/pip_install/#obtaining-information-about-what-was-installed. The goal is to get the list of files that will be downloaded along with their SHA hashes (without actually creating the environemtn). We could use that to recreate the exact environment for CI/CD

[zanieb]

This sounds like the purpose of uv pip compile — I think this is just a flag in pip install because they don't have the pip-compile interface.

[charliermarsh]

I think the difference is that compile won’t tell you the specific wheels or source distributions that you’d need to install for the current platform.

[sfc-gh-nsharma]

Yes, --dry-run + --report has a very detailed machine-readable output.
https://pip.pypa.io/en/stable/reference/installation-report/#example

[edgarrmondragon]

Can you expand on the use-case? Why would this be an output of pip install rather than pip compile?

For us, we're PoCing a requirements-lock feature and we support two "venv backends":

• virtualenv + pip
• uv

For the first one we were planning to use the --report output to get the resolved direct dependencies. The benefit of having this feature in uv would be writing the parse logic only once (for the JSON output). Without this, we either need a dependency on pip-tools and parse the same requirements.txt style output from both tools, or write different parsing logic for pip and uv.

[yajo]

My use case is that I package a huge project with lots of dependencies (a meta-repo; some are editable) using https://github.com/nix-community/dream2nix. In Nix world, all files must either be built offline or hash-verified if online. The locking process uses pip and is terribly slow. I'd love to speed it up with uv, but uv lacks the report feature, which is the one used by the lock process to produce valid nix FODs.

I checked by using uv pip compile --generate-hashes, but the output is hard to parse and also doesn't have details about what files use what hashes. It's just a list of hashes but I don't know which is which. Also it seems to build wheels for sdists, when I'd be happy with just the hash of the sdist as pip --dry-run --report gets, as the real build is done later by nix anyway.

[charliermarsh]

Also it seems to build wheels for sdists...

(Just as an aside: you often need to build a wheel in order to perform dependency resolution.)

[yorickvP]

@yajo I implemented a uv solver with dream2nix at https://github.com/datakami/cognix/blob/main/modules/pip-uv/default.nix, but it requires a patched uv

My patch isn't really upstreamable, but it would be great to instead have --report upstream.