Leveraging & supporting pyproject.toml more within Bazel

[JeroenSchmidt]

Inspired by the recent PR from @golithe.

Reducing the bifurcation of the contents of pyproject.toml and bazel is something that I've been thinking a lot about but haven't been able to dive into. I would love to hear what the community and maintainers thinks about this:

• Would it be appropriate to provide a target that generates pyproject.toml files (from the BUILD files) to maintain interoperability while people adopt Bazel?
• Inversely; is it a good idea to leverage the information in pyproject.toml files to also bootstrap bazel (with gazel) in an existing python repos?
  • For example using tool.uv.sources & project.optional-dependencies to determine relationships between subpackages.
  • This could become quite powerful if it also made it easy to define multiple hubs (e.g. lower bound and upper bound resolution of pip requirements)

[gzm0]

I'm coming here from the PR. I've worked with @golithe on https://github.com/datahouse/bazel_buildlib

is it a good idea to leverage the information in pyproject.toml files

IMHO this 100%.

It makes integration with other tools (Dependency update tooling ala Renovate, IDEs, non-bazel versions of tools, agents, etc.) so much easier.

We often just go through a custom repository / module extension, so don't even bother with keeping a starlark version of the same info (YMMV, probably this is not a good idea for bazel package specific things).

[golithe]

is it a good idea to leverage the information in pyproject.toml files

i second this!