pyproject.toml schemas assumes poetry, breaks for pdm (and others)

[dsully]

trafficstars

https://github.com/tamasfe/taplo/blob/master/site/site/public/schemas/pyproject.toml.json

I'm not sure how one would update this to include multiple "providers".

Thanks

[bollwyvl]

Yeah, it would take a good deal of effort to properly capture all the possible build backends, but very worthwhile. Sadly, few of these tools publish anything like a schema, but as all of these put their stuff in different keys, they shouldn't conflict.

flit, for example, prefers using the PEP621 fields, but still supports the custom ones in tool.hatch, while hatch goes nuts, and puts stuff all over.

A bit of flattening of definitions would make this more tractable, and indeed, using TOML as the authored source of truth could make this more scalable:

type = "object"
"$ref" = "#/definitions/_top"

[definitions._top]
type = "object"

[definitions._top.properties]
tool = {"$ref": "#/definitions/tool"}
build-system = {"$ref": "#/definitions/build-system"}

[definitions.build-system]
# ...

[definitions.tool]
type = "object"

[definitions.tool.properties]
poetry = {"$ref": "#/definitions/tool-poetry"}
flit =   {"$ref": "#/definitions/tool-flit"}
hatch =  {"$ref": "#/definitions/tool-hatch"}
# black
# mypy
# ruff
# ...

[definitions.tool-poetry]
# ...

[definitions.tool-flit]
# ...

[definitions.tool-hatch]
# ...

[panekj]

Schemas should be delivered from SchemaStore nowadays instead of our customs.