uv tree often has no output

[dimbleby]

sometimes uv tree will decline to say anything

[project]
name = "foo"
version = "0.1.0"
requires-python = ">=3.13"
dependencies = [
  "aiohttp>=3.9.5",
]

$ uv tree   # NB looks good
Resolved 10 packages in 19ms
foo v0.1.0
└── aiohttp v3.10.10
    ├── aiohappyeyeballs v2.4.3
    ├── aiosignal v1.3.1
    │   └── frozenlist v1.4.1
    ├── attrs v24.2.0
    ├── frozenlist v1.4.1
    ├── multidict v6.1.0
    └── yarl v1.15.5
        ├── idna v3.10
        ├── multidict v6.1.0
        └── propcache v0.2.0

$ uv tree --package propcache  # NB no output
Resolved 10 packages in 1ms

$ uv tree --package propcache --invert  # NB apparently invert will tell me something
Resolved 10 packages in 1ms
propcache v0.2.0
└── yarl v1.15.5
    └── aiohttp v3.10.10
        └── foo v0.1.0

$ uv tree --package yarl  # NB nothing to say about yarl
Resolved 10 packages in 1ms

$ uv tree --package yarl --invert  # NB even when inverted
Resolved 10 packages in 1ms

is there some not-so-obvious logic to this that I am missing?

[j178]

The --package flag refers to a package within the workspace itself, not a dependency. I agree that this flag can be a bit confusing.

[dimbleby]

The --package flag refers to a package within the workspace itself

it certainly must be more subtle than that, per the examples of uv tree --package propcache --invert and uv tree --package yarl --invert. Neither of these is "a package within the workspace itself", the results appear to be inconsistent

[zanieb]

Thanks! Seems like something weird is going on here.

[dimbleby]

I think the actual answer is that the tree display insists on starting from a "root".

• For non-inverted trees that is workspace packages.
• For inverted trees that is dependencies with no further dependencies

imo the first is maybe defensible - but it would be more helpful to show the tree starting from the package the user asked for.

also imo, the second is undesirable: eg it makes it harder for me to answer a question like "why is yarl installed?"

[zanieb]

I think @charliermarsh is likely to have some insight.

I agree it seems sensible that --package should just start at an arbitrary package in the tree — but it's worth noting this is inconsistent with the meaning of --package in every other project command. I kind of feel like --package should have been --member 😢.

[charliermarsh]

Yeah I think some things are going wrong here. I think we naively limit the tree to "roots" because we don't want to show duplicates.

[charliermarsh]

(So yes, definitely some bugs here.)

[charliermarsh]

I'm rewriting this to fix these problems and make things simpler.