Bazel support

[SamuelMarks]

Description

Bazel is popular. As is CMake, Meson, make, etc.

It would be great to have an official hatch plugin focussing on Bazel (what I care about right now) and maybe these others also (as others care about the others). Solving for one is expected to solve for all.

Use case/motivation

Hatch should have a clear path to including dependencies with their own non-Python-world build systems in a regular Python worktree; primarily for building Python wrapper packages.

This absolves Hatch of including ways of directly providing linker flags and compiler flags and resolving dependencies and packaging, and absolves the ecosystem of having to rewrite-in-Hatch.

Related issues

#1817 and his whole project https://github.com/eguiraud/hatch-bazel-and-pybind11

Related also: https://github.com/rmorshea/hatch-build-scripts
(for executing arbitrary commands and storing their assets for usages in later stages)

Are you willing to submit a PR?

• Yes I am willing to submit a PR!

Code of Conduct

• I agree to follow the Python Software Foundation's Code of Conduct

[ofek]

Hey there! Generally speaking, I'm interested in this. Can you explain what's required in particular?

[SamuelMarks]

Hey!

Great that you're interested. Ok well I'll need to deep-dive into hatch. Will probably implement the whole thing with no LLMs or other AI-tools.

But for documentation purposes and in response to your interest, here's a quick run-through of what an implementation is likely required to implement (from three popular LLMs):

---

Complexity	Feature	Description
🟢 Basic	Bazel Build Invocation	Add a Hatch builder that runs bazel build //target and collects outputs.
🟢 Basic	Pyproject Config Mapping	Allow [tool.hatch.build.bazel] section in pyproject.toml to specify Bazel targets.
🟡 Intermediate	Artifact Packaging	Automatically copy Bazel outputs (e.g., .so, .dll) into the wheel structure.
🟡 Intermediate	Bazel Clean Integration	Map Hatch’s clean command to bazel clean.
🟡 Intermediate	Bazel Test Hook	Run bazel test //... when Hatch’s test lifecycle is invoked.
🟠 Advanced	Dependency Bridging	Sync Python dependencies declared in Hatch with Bazel’s requirements.txt or pip_install.
🟠 Advanced	Multi-Target Builds	Support multiple Bazel targets per Hatch project, merging outputs into one wheel.
🔴 Expert	Cross-Platform Support	Handle Bazel builds across Linux, macOS, and Windows with platform-specific rules.
🔴 Expert	Incremental Build Caching	Integrate Bazel’s cache with Hatch’s build cache for faster rebuilds.
🔴 Expert	Hybrid Testing	Unify pytest with Bazel test results into a single Hatch report.
🚀 Cutting Edge	Full Bazel Workspace Integration	Allow Hatch to manage Bazel workspaces directly, bridging Python + native code seamlessly.

---

Complexity	Feature	Implementation Scope	Key Technical Challenges
Low	Basic Bazel BUILD file generation	Generate minimal BUILD files for pure Python packages	- Parsing pyproject.toml metadata - Basic Python library rule generation
Low-Medium	Detect and use existing Bazel configurations	Read and integrate pre-existing Bazel BUILD files	- Metadata compatibility - Configuration file parsing
Medium	Native extension compilation support	Add rules for compiling C/C++/Rust extensions	- Cross-compilation support - Toolchain detection - Dependency resolution
Medium-High	Dependency mapping	Map Python package dependencies to Bazel targets	- Complex dependency graph parsing - Version constraint handling - Multiple repository support
High	Cross-platform build configuration	Generate platform-specific Bazel build configurations	- OS-specific compilation flags - Multi-architecture support - Conditional compilation rules
High-Expert	Advanced toolchain integration	Support custom toolchains and complex build scenarios	- Hermetic build environments - Remote execution support - Advanced caching mechanisms

---

#	Feature	Complexity	Description	Prompt Concept to use
1	Plugin Skeleton	Low	distinct Python package structure required to register a Hatch plugin entry point.	"Generate the directory structure and pyproject.toml for a new package named hatch-bazel, including the hatch entry point registration pointing to a blank class."
2	The Build Hook Interface	Low	The Python class inheriting from BuildHookInterface with the stubs for initialize and finalize.	"Write a Python class BazelBuildHook that inherits from hatchling...BuildHookInterface. Add a logger and print a message during the initialize phase to verify it runs."
3	Configuration Parsing	Low	Reading the [tool.hatch.build.hooks.bazel] section from the user's pyproject.toml.	"Implement logic in the initialize method to read a targets list and a basel_bin_path string from the plugin configuration dictionary, supplying defaults if missing."
4	Subprocess Execution	Medium	Securely invoking the Bazel binary to build the requested targets.	"Write the code to construct a subprocess.run command that calls bazel build on the configured targets. Ensure it captures stdout/stderr and raises an error on failure."
5	Symlink Resolution	Medium	Bazel produces symlinks in bazel-bin. These must be resolved to real paths to be zipped into a wheel.	"Create a helper function that takes a Bazel target string (e.g., //src:lib), locates the resulting file in the bazel-bin directory, and resolves the symlink to the absolute real path."
6	Artifact Injection	High	Telling Hatch to include the compiled binary in the final wheel using force_include.	"Update the hook to map the resolved binary paths from the previous step into the build_data['force_include'] dictionary, placing them inside the specific project package folder."
7	Wheel Metadata (Pure vs Binary)	Medium	Ensuring the resulting wheel is marked as binary (platform-specific) rather than generic Python.	"Write code to modify build_data['pure_python'] to False and ensure the wheel is tagged correctly so pip doesn't treat it as a cross-platform Any/Any wheel."
8	Cleanup Hook	Low	Removing temporary artifacts or bazel-bin hints after the build completes.	"Implement the finalize method in the class to perform executed cleanup, such as creating a clean command or verifying the state of the workspace after the build."
9	Advanced Argument Passing	Medium	Allowing the user to pass extra flags (e.g., --compilation_mode=opt) via Pyproject or CLI.	"Extend the configuration parser to accept startup_args (before 'build') and build_args (after 'build') and inject them into the subprocess call."
10	Protos & Generated Sources	High	Handling generated .py files (like protobufs) that Bazel creates but need to be treated as source code, not binaries.	"Add logic to detect if a Bazel output is a .py file. If so, copy it into the local source tree temporarily instead of using force_include, so Hatchling treats it as a standard source file."

---

Let me know how accurate/inaccurate this is and whether you want this implemented directly or as a plugin as these^ propose.

[ofek]

I appreciate your willingness to get feedback (I'd like to see that prompt!) but unfortunately I have limited time and it wasn't extremely helpful upon a quick skim. Let me approach this in a different way. As a user without knowledge of any implementation details:

• What would one want out of such an integration?
• What are the practical UX implications of such support?
• What is difficult or impossible to achieve today?

Also, it may not be immediately relevant but it should be known that I have a strong bias against what rules_python does by default (what Google happens to do/require) and I would only ever personally use https://github.com/aspect-build/rules_py

[SamuelMarks]

So I think the main thing is that every build system tries to replace all other build systems; like that old xkcd comic. My development philosophy is aggressive [open-source] interoperability.

bazel can replace all other build systems.
cmake can replace all other build systems.
Makefiles can replace all custom written workflows, including to replace all other build systems.

pip/hatch can replace all other build systems?

Now it'd be annoying to actually change the upstream code that relies on something else in favour of native python toolchain ecosystem; especially whence that codebase lacks Python.

It is well-known at Google that BUILD files (bazel) permeates every language and just about every internal and external codebase. Projects with public facing pyproject.toml exclusive codebases will internally have BUILD files and a copybara process that utilises them.

Bazel has many advantages, like: concurrency; caching; lingua franca-ness, &etc.

But it's not native. Explicitly.

pip is native. hatch is about as native as you can get; being situated within the pypa org. And hatch works with uv and regular Python (system, pyenv, etc.) also.

So let's use the regular Python setup workflow for both Python and whatever is needed to get Python wrappers working (including third-party .dlls / .sos / .dylibs etc. ; managing language toolchains; configuring linker and build flags; percolating env vars) all from one pyproject.toml interface.

TL;DR I don't want care what build systems people use for Python. Each are theoretically interchangeable; let's make them practically so!