tree does not properly handle multiple versions of the same package

[charliermarsh]

This is possible in uv tree (but not pip tree typically), since the lockfile can contain multiple versions. Notice the strange result here:

#[test]
fn multi_version() -> Result<()> {
    let context = TestContext::new("3.12");

    let pyproject_toml = context.temp_dir.child("pyproject.toml");
    pyproject_toml.write_str(
        r#"
        [project]
        name = "project"
        version = "0.1.0"
        # ...
        requires-python = ">=3.12"
        dependencies = [
            "anyio==3.3.0 ; sys_platform == 'win32'",
            "anyio==2.0.0 ; sys_platform != 'win32'",
        ]
    "#,
    )?;

    uv_snapshot!(context.filters(), context.tree(), @r###"
    success: true
    exit_code: 0
    ----- stdout -----
    project v0.1.0
    └── anyio v2.0.0
        ├── idna v3.6
        ├── sniffio v1.3.1
        ├── idna v3.6
        └── sniffio v1.3.1
    └── anyio v3.3.0 (*)
    (*) Package tree already displayed

    ----- stderr -----
    warning: `uv tree` is experimental and may change without warning
    Resolved 5 packages in [TIME]
    "###
    );

    Ok(())
}

[charliermarsh]

Can we make all the hash maps there keyed on (name, version) instead of just name?

[ChannyClaus]

so is the expected output for the above pyproject.toml the below?

 project v0.1.0
 ├─── anyio v3.3.0
 │   ├── idna v3.6
 │   └── sniffio v1.3.1
 └── anyio v2.0.0
     ├── idna v3.6
     └── sniffio v1.3.1

(relatedly, is there a design doc for uv's higher level entrypoints? i think i have a rough idea around the motivation for it but not quite enough to immediately see what should be the desired outcome here)

[charliermarsh]

@ChannyClaus -- Yeah, that looks right to me. I don't know that we have a design doc on GitHub, but we're starting to build up the documentation here -- it's still a work-in-progress: https://docs.astral.sh/uv/

[eth3lbert]

How about displaying only the packages available on the current platform?

[zanieb]

It seems useful to inspect the lockfile tree as a whole though

[charliermarsh]

@eth3lbert -- That could be useful but I think it would be a separate flag.

[eth3lbert]

Fair enough! cargo tree also has a --target option. By default is the host platform, but can also be set to "all" or other specific values.

[charliermarsh]

(We could accept the --python-platform and --python-version flags here.)

[charliermarsh]

It's actually even harder than this, because we can have a single package at a single version but multiple URLs (#5294).