Bundles: a third registry package type?

[calledtoconstruct]

Omarchy already has a clear idea of curated installs (Install menu categories, omarchy-install-dev-env, the Kids profile work in #9750), and Discussion #12342 asks for task presets like "Web Design / Gaming / Streaming." Separately, Discussion #7382 and PR #9557 explore how plugins could declare package dependencies and get clean removal.

I'd like to propose bundles as a third data-only package type in the registry, next to plugins and themes, rather than as a new dependency graph on plugins.

What a bundle would be

A declarative package that groups everything someone needs for an activity. Examples: Storm Chaser (weather plugins, RSS, photo/video tools, AI skills), Web Designer (coding tools already in the Install menu, Cloudflare setup on first project), Omarchy Kids variants, sailing, trip planning.

A bundle would declare:

• packages (apps) and plugins as separate lists
• AI skills and config templates
• optional conflicts (e.g. single-child Kids vs multi-child Kids)
• an optional project-creation script (never run at install)

Install stays declarative, same rule as plugins and themes: the installer never runs bundle code. Scripts only run when the user deliberately creates a project. Removal uses reference counting so shared packages and plugins stay if another installed bundle still needs them.

Why a third type, not plugin features

The registry design already says plugins should stay free of a dependency graph, and themes are the data-only template. A bundle type keeps that intact and gives activity packs a home without stretching what a Quickshell plugin is. DHH's split of plugins (shell) vs apps also fits: a bundle lists both, rather than mixing them into one kind.

Questions for Ryan / maintainers

1. Does a newer registry client exist beyond the Aug plugin-registry-client branch? I don't want to build on a stale prototype.
2. Is omarchy bundle add publisher/name the right shape, mirroring omarchy plugin add / theme?
3. For package ownership and conflicts, would generating a local pacman meta-package per bundle (as sketched in Let shell plugins declare optional package dependencies #7382) be acceptable, or is a self-contained ledger preferred?
4. Would you rather see a small plans/bundles.md first, or a thin PR that only adds the package type to the registry?

Happy to open a plan doc, help with the meta-package helpers, or back related PRs (#7946 menu entries, #9750 Kids profile) instead of competing with them. Related: #7382, #9557, #12342, #9750.

[calledtoconstruct]

There is a prototype on my fork, plus five example bundles, if you want to try this on an installed Omarchy.

• Commands: https://github.com/calledtoconstruct/omarchy/tree/bundles
• Examples: https://github.com/calledtoconstruct/omarchy-bundles (webdev, creator, local-ai, study, gaming)

Clone the branch and point the session at it with the dev link, then reboot. That is what makes the menu, the notification, and omarchy bundle agree. A PATH change in one terminal can dry-run the command, and it leaves the rest of the session on the packaged install.

git clone -b bundles https://github.com/calledtoconstruct/omarchy.git
git clone https://github.com/calledtoconstruct/omarchy-bundles.git
omarchy dev link "$PWD/omarchy"

After reboot:

omarchy bundle add --dry-run ./omarchy-bundles/bundles/gaming

Drop --dry-run to install. omarchy bundle list and omarchy bundle remove gaming undo it. omarchy dev unlink and a reboot return you to the packaged install. publisher/name is recognized and still refused. Ownership is a local ledger, not a generated pacman meta-package. The manual on that branch is manual/52-bundles.md.

[calledtoconstruct]

A sixth example is in the catalog: cyber.

It is the lab bench for the "can Omarchy do pentesting?" question. Kali, Parrot, BlackArch, and Fedora Security Lab each turn that bench into its own operating system or a giant metapackage. This one installs and removes like the other examples. The packages are official Arch tools for capture, web inspection, reverse engineering, forensics, offline password recovery, and a host audit. Metasploit, Hydra, Aircrack-ng, and SQLmap are not in it.

It also adds things that were not already an Arch package: a bar badge (omarchy-cyber-lab) that shows a capture already running and whether scope.md names who authorized the work, and skills that file notes from a pcap, a firmware listing, or an audit you already ran. The badge does not start a capture.

It still needs the bundles branch of my fork. publisher/name is recognized and still refused.