hatch-oxidizer

Description

Feature / Concept: Native Executable Target Plugin Interface (e.g. hatch-oxidizer / hatch-pyinstaller)

Is your feature request related to a problem? Hatchling does a fantastic job handling wheel and sdist build targets (and hatch-cython covers native extensions brilliantly). However, for applications targeting non-developer end-users (especially on Windows bare-metal without Python, WSL, or Docker), the final target is often a single zero-dependency standalone binary (.exe).

Right now, packaging to an executable requires stepping outside Hatchling into external post-build scripts (cx_Freeze, raw pyinstaller CLI, or PyOxidizer Starlark configs).

Describe the solution you'd like It would be awesome to formalize an executable target builder plugin spec for Hatchling (or showcase an official pattern for [tool.hatch.build.targets.binary]).

Imagine being able to declare binary compilation right alongside Cython hooks in pyproject.toml:

[build-system]
requires = ["hatchling", "hatch-cython", "hatch-oxidizer"]
build-backend = "hatchling.build"

[project]
name = "my-cli-tool"
version = "0.1.0"
dependencies = ["click"]

# 1. First-pass Cython compilation
[tool.hatch.build.targets.wheel.hooks.cython]
dependencies = ["hatch-cython"]
options = { compile_py = true }

# 2. Standalone Binary Target (PyOxidizer / Rust PyEmbed under the hood)
[tool.hatch.build.targets.oxidizer]
dependencies = ["hatch-oxidizer"]
target_name = "mytool.exe"
packaging_policy = "in-memory-only"

### Use case/motivation

_No response_

### Related issues

_No response_

### Are you willing to submit a PR?

- [ ] Yes I am willing to submit a PR!

### Code of Conduct

- [x] I agree to follow the Python Software Foundation's [Code of Conduct](https://policies.python.org/python.org/code-of-conduct/)