- G-code 66.7%
- Python 24.5%
- Rust 4.8%
- Starlark 1.2%
- JavaScript 0.7%
- Other 1.9%
| .claude | ||
| bazel | ||
| bin | ||
| projects | ||
| third_party/bazel | ||
| tools | ||
| .bazelignore | ||
| .bazelrc | ||
| .bazelversion | ||
| .editorconfig | ||
| .envrc | ||
| .gitattributes | ||
| .gitignore | ||
| BUILD.bazel | ||
| HACKING.md | ||
| LICENSE | ||
| MODULE.bazel | ||
| pyproject.toml | ||
| README.md | ||
| rustfmt.toml | ||
| uv.lock | ||
| WORKSPACE | ||
arrdem/source
Hello and welcome to my personal sandbox.
Source is a somewhat greenfield project in monorepo infrastructure and organization, allowing me to prototype tooling and rules in a somewhat real environment. Source is also the home for much of TireFire Heavy Industries and other projects.
This repo is built around a very specific vision of how monorepos "should" work; to wit monorepos are best understood as scaffolding or superstructure which allows other components to orient themselves and interact.
A wise man once said "Don't make me think". While I hate to hand it to golang, it is entirely correct in identifying the ergonomic and organizational value that sheer consistency can provide. Engineers (or agents!) who have to dig around to find the tests or remember how a given component is released are wasting time.
A well maintained monorepo needs to provide a single obvious pattern for how things sit next to each other, and how they depend between each other. It needs to allow an application to be close (in terms of directory structure; ideally co-located) with its tests, documentation and deploy infrastructure.
I use the /projects/ tree to warehouse broadly internally consistent projects.
Critically, projects ARE NOT organized by language or other concerns.
All projects are created equal.
All projects use the same deploy tooling (bazel run :deploy).
All projects use the same test interface (bazel test ...).
Want a new project? Here's an entirely obvious template of which there are a dozen existing examples, go forth and stamp one out.
No longer need a project? Just delete the entire tree. It'll be in the git log forever, and identifying references to it should be trivial thanks to consistency.
Active projects
| Project | Description | Tags |
|---|---|---|
| arstotzka | Auth token gateway service | k8s |
| batvision | Network scanning and monitoring | homeassistant |
| cairn | Content-addressed storage service (Rust) | k8s, bazel |
| cram | Dotfile/config package manager | |
| doorman | Access control gateway | k8s, LLMs |
| klepsydra | Composable temporal expression language | |
| localscene | Local event aggregator | |
| locksmith | WebSocket-based lock service | homeassistant |
| monoversion | Calver monorepo versioning tool | |
| rules_py_dist | Python sdists and bdists | Bazel |
| rules_zapp | Python zipapps | Bazel |
| sloppy-joe | LLM experimentation sandbox | LLMs |
| tiller | Kubernetes manifest generator | k8s |
| zfs-provisioner | ZFS-backed k8s persistent volumes | k8s |
| zonekeeper | DNS zone management | k8s, homelab |
Build & deploy
Bazel 9 with bzlmod handles builds, OCI image packaging, and deploys:
bazel build //projects/localscene/... # build a project
bazel run --config=release //projects/foo:deploy # build, push, apply
See HACKING.md for development setup.
License
Copyright © Reid D. McKenzie, published under the Anti-Capitalist Software License v1.4.
Commercial licensing negotiable upon request.