Adding package dependency trace to `uv export`

[zmeir]

I have a project I'm developing with uv. I use uv lock to lock my dependency versions for my app, and uv sync --frozen to install my development and test environments.

The framework I use to deploy my app uses a requirements.txt file to install the application's dependencies.
Previously I used uv pip compile to generate the requirements.txt file, but I figured since I already have the uv.lock file, I can save the extra resolution step and just use uv export --frozen. And it works perfectly!
However, there is one small thing - the uv pip compile output is more verbose and adds comments under each package to show its dependency trace. Conversely, uv export does not, and only shows the package versions (like pip freeze).

Here is an example for the pyproject.toml

[project]
name = "test-uv-export"
version = "0.0.dev0"
requires-python = ">=3.10"
dependencies = [
    "pandas",
    "numpy",
]

This is how the output of uv pip compile pyproject.toml looks:

# This file was autogenerated by uv via the following command:
#    uv pip compile pyproject.toml
numpy==2.1.1
    # via
    #   test-uv-export (pyproject.toml)
    #   pandas
pandas==2.2.3
    # via test-uv-export (pyproject.toml)
python-dateutil==2.9.0.post0
    # via pandas
pytz==2024.2
    # via pandas
six==1.16.0
    # via python-dateutil
tzdata==2024.2
    # via pandas

And this is the output from uv export --frozen --no-hashes (after having previous ran uv lock):

# This file was autogenerated by uv via the following command:
#    uv export --frozen --no-hashes
numpy==2.1.1
pandas==2.2.3
python-dateutil==2.9.0.post0
pytz==2024.2
six==1.16.0
tzdata==2024.2

Is it possible to add the same dependency trace comments for the uv export output?

This is not a real issue when the consumer of the requirements.txt file is an automated system, but I found the uv pip compile output can be helpful when trying to debug the root cause of deployment failures due to unsuccessful dependency installations.
Of course this is not a very pressing issue, since you can always trace the origin of a dependency through the uv.lock file, but I thought since the information is already there when uv export generates its output, then maybe it can be done without much effort. Or maybe even this option already exists I just couldn't find how to enable it...

[zanieb]

You might want to use uv tree to debug your dependency install failures instead?

[zmeir]

Cool, thanks!

That still means I have to log into the environment that failed and run the command there to debug, instead of just looking up the requirements.txt file from the output. In my team we have a handful of developers working on many projects, so sometimes the person debugging a failure doesn't have the project cloned and set up with a working environment when starting to debug, so pulling the failed version to get the current uv.lock file and then running uv tree can take a while longer (especially for the less experienced folks).
The alternative of just looking at the build log and seeing which package failed, and then looking where that package came from in the requirements.txt file (from GitHub or the CI logs/artifacts), is still simpler I think. But I understand this might be a very niche use-case...
I should also note that in certain cases we don't even keep the uv.lock file, for example when exporting requirements.txt with --resolution lowest to test that our app works with the lowest versions of our dependencies. It is done ad-hoc by the CI and we don't keep the uv.lock file for that resolution because we don't want it to override the on with the default --resolution highest.

Anyway, this is certainly not a big deal, just want to share this idea.

[trim21]

a example using uv tree if someone is wondering how:

uv tree --invert --package colorama

uv tree --invert --package colorama
Using CPython 3.10.16
Resolved 60 packages in 1ms
colorama v0.4.6
├── click v8.1.8
│   ├── litestar v2.15.1
│   │   └── project[jinja] v0
│   ├── rich-click v1.8.8
│   │   └── litestar v2.15.1 (*)
│   └── uvicorn v0.34.0
│       └── project v0
└── pytest v8.3.4
    └── project v0 (group: dev)
(*) Package tree already displayed