## Summary
This expands `uv workspace metadata` with many of the fields that are
found in `uv.lock` so that we have a format with information about the
dependency graph/resolution that we're willing to call stable and have
people rely upon (rather than `uv.lock` which we'd rather you don't try
to interpret).
To a first approximation you can think of this as "uv.lock but
serialized to json" but with the fields a bit more limited for now (easy
to add later).
The biggest intentional divergence with uv.lock is that we favour
encoding the dependency graph in a form that looks more like our
internal "resolve" graph, in that hopes that it will simplify the work
of anyone doing analysis on the graph (we structure our internal graph
like this for a reason).
Specifically, the `resolve` field contains the entire dependency graph,
with packages desugarred into several different nodes. There are 4 kinds
of nodes (really 3, the build nodes will only be introduced when we
establish build-dependency locking):
* packages: `mypackage==1.0.0 @ registry+https://pypi.org/simple`
* extras: `mypackage[myextra]==1.0.0 @ registry+https://pypi.org/simple`
* groups: `mypackage:mygroup==1.0.0 @ registry+https://pypi.org/simple`
* build: `mypackage(build)==1.0.0 @ registry+https://pypi.org/simple`
package nodes hold additional metadata about the package itself, and ids
of the associated extra/group/build nodes.
---
A package like this:
```toml
[project]
name = "mypackage"
version = "1.0.0"
dependencies = ["httpx"]
[project.optional-dependencies]
cli = ["rich"]
[dependency-groups]
dev = ["typing-extensions"]
[build-system]
requires = ["hatchling"]
build-backend = "hatchling.build"
```
will get 4 nodes with the following edges (Version and Source omitted
here for brevity):
* `mypackage`
* `httpx`
* `mypackage(build)`
* `hatchling`
* `mypackage[cli]`
* `mypackage`
* `rich`
* `mypackage:dev`
* `typing-extensions`
Note that `mypackage[cli]` has a dependency edge on `mypackage` while
`mypackage:dev` does not. This is because
`mypackage[cli]` is fundamentally an augmentation of `mypackage` while
`mypackage:dev` is just a list of packages that happens to be defined by
`mypackage`'s pyproject.toml.
The resulting nodes for `mypackage` will look something like:
<details>
<summary>json blob</summary>
```json
{
"resolve": {
"mypackage==1.0.0 @ editable+.": {
"name": "mypackage",
"version": "1.0.0",
"source": {
"editable": "."
},
"kind": "package",
"dependencies": [
{
"id": "httpx==3.6 @ registry+https://pypi.org/simple"
"marker": "sys_platform == 'linux'"
},
],
"optional_dependencies": [
{
"name": "cli",
"id": "mypackage[cli]==1.0.0 @ editable+."
},
],
"dependency_groups": [
{
"name": "dev",
"id": "mypackage:dev==1.0.0 @ editable+."
}
]
"build_system": {
"build_backend": "hatchling.build",
"id": "mypackage(build)==1.0.0 @ editable+."
}
"sdist": { ... },
"wheels": [ ... ]
},
"mypackage:dev==1.0.0 @ editable+.": {
"name": "mypackage",
"version": "1.0.0",
"source": {
"editable": "."
},
"kind": {
"group": "dev"
},
"dependencies": [
{
"id": "typing-extensions==1.2.3 @ registry+https://pypi.org/simple"
},
]
},
}
"mypackage[cli]==1.0.0 @ editable+.": {
"name": "mypackage",
"version": "1.0.0",
"source": {
"editable": "."
},
"kind": {
"extra": "cli"
},
"dependencies": [
{
"id": "rich==2.2.3 @ registry+https://pypi.org/simple"
},
{
"id": "mypackage==1.0.0 @ editable+."
},
]
},
"mypackage(build)==1.0.0 @ editable+.": {
"name": "mypackage",
"version": "1.0.0",
"source": {
"editable": "."
},
"kind": "build",
"dependencies": [
{
"id": "hatchling==3.2.3 @ registry+https://pypi.org/simple"
},
]
}
}
}
```
</details>
## Test Plan
Snapshots
The content is unchanged.
I'm planning to expand the content in the Python version and Platform
support files and generally don't like that these are mixed.
Aria Desires