Reconcile PEP517's directory-centric approach with Bazel's target-centric one

[nicholasjng]

The first obstacle in this project is also very important to get right for usability.

A typical wheel build invocation might look like this:

# in the Python project directory.
python -m build . -w

Notice the dot "." commanding that build should package the current directory with the build backend specified in pyproject.toml (which is required to exist in the target directory iiuc).

In Bazel, this looks different, and a wheel will be defined as a target in a BUILD file (for simplicity, let's assume it to be in the same directory as pyproject.toml).

How should bazelbuild go about discovery? There is the option of encoding the target in the bazelbuild tool config in pyproject.toml:

[build-system]
requires = ["bazelbuild"]
build-backend = "bazelbuild"

[project]
name = "my-proj"
version = "0.1.0"

[tool.bazelbuild]
targets = [
    { name = "my_proj", target_name = "//path/to/my-proj:wheel" },
    ...
]

That has the advantage that it can become a mapping of targets, and one could build multiple packages with essentially the same command. It's presumably also a good workflow in monorepos.

On the other hand, this is more verbose than e.g. setuptools or scikit-build-core is. Another option is autodiscovery, whereby e.g. a folder with pyproject.toml for a project named "my-proj" would by default make bazelbuild look for a target named my-proj (or its snake case equivalent) in the BUILD file of the same location.