litestar-build

Package Litestar applications as self-contained wheels and PyApp onefile binaries with CI release pipelines.

Updated Aug 17, 2026
One-click install
npx skills add https://github.com/renjianguo666/litecms --skill litestar-build-renjianguo666
Or copy as Structured Prompt for Agent
Please help me install this Agent Skill.
Skill: litestar-build
Source: https://github.com/renjianguo666/litecms/tree/main/.agents/skills/litestar-build
Command: npx skills add https://github.com/renjianguo666/litecms --skill litestar-build-renjianguo666

SYSTEM DOCUMENTATION & REQUIREMENTS

💡 This Skill includes references (resource) components.

What problem does it solve? Building a Litestar app with a bundled frontend often produces wheels that silently drop the compiled JavaScript and CSS, and shipping a single-file binary that works offline or on older Linux distros requires deep knowledge of PyApp, Hatchling, and cargo-zigbuild. This Skill codifies the exact build-side packaging patterns so wheels, onefile binaries, and GitHub Actions release pipelines work correctly the first time. ## Core Features & Use Cases - Self-contained wheel builds: Configure Vite/litestar-vite output directories inside the Python package and choose between Hatchling force-include or ignore-vcs = true so frontend assets, SQL migrations, and templates ship inside the wheel. - PyApp onefile binaries: Two flavors covered — simple hatch build --target binary for PyPI-connected users, and an advanced offline bundler using python-build-standalone, a patched PyApp app.rs install directory, and cargo zigbuild for glibc 2.17 compatibility. - GitHub Actions CI and release pipelines: Reusable test-matrix workflows, composite setup actions for pinned uv and Bun versions, and tag-triggered release workflows that build one wheel, matrix-compile per-platform binaries, and publish a GitHub release. - Use Case: You have a Litestar + React app and need to ship an air-gapped enterprise installer. Follow the advanced PyApp pattern to produce a ~500 MB onefile that extracts to ~/.myapp/runtime/ and passes a network-isolated distroless smoke test. ## Quick Start Ask the assistant to configure your Litestar project so the Vite build output lands inside the Python package and uv build --wheel produces a self-contained wheel with the frontend included.

Frequently Asked Questions about litestar-build

High-intent search queries and answers about installing and using this skill.

FAQPage Schema
How do I bundle a Vite frontend into a Python wheel with Hatchling?

Point Vite's build.outDir (or litestar-vite's bundle_dir) to an absolute path inside the Python package directory, then either add a force-include entry for the built asset directory or set ignore-vcs = true in the Hatchling wheel target. Run the asset build before uv build --wheel.

How do I build a PyApp onefile binary for a Python app?

Add a [tool.hatch.build.targets.binary] section with pyapp-version, python-version, and scripts matching your console entry point, then run uv run hatch build --target binary. For offline or custom install locations, use a custom bundler with python-build-standalone and cargo zigbuild.

Why is my built wheel missing the JavaScript and CSS frontend files?

The Vite output directory is outside the Python package listed in Hatchling's packages config, so Hatchling silently drops it. Set build.outDir to an absolute path under src/py/<pkg>/ and verify with unzip -l dist/*.whl.

Should I use force-include or ignore-vcs in Hatchling for built assets?

Pick exactly one. force-include gives explicit per-directory control while keeping .gitignore authoritative; ignore-vcs = true ships everything under the package tree with one switch. Mixing both causes duplicate-file warnings and unpredictable wheel contents.

Why does my PyApp binary fail on CentOS 7 or older Linux distros?

Plain cargo build links against the build runner's modern glibc, producing GLIBC version not found errors on older systems. Use cargo zigbuild --target x86_64-unknown-linux-gnu.2.17 to link against glibc 2.17, and statically link libbz2 and liblzma.

When should I avoid the advanced PyApp bundling approach?

Skip it when end users have PyPI network access, target platforms run recent glibc, and the default XDG install location is acceptable. The advanced path adds roughly 500 lines of Python plus workflow YAML and is only justified for air-gapped or custom install-location requirements.