chore(packages): include service_livekit in service_install_all #120

Merged

sameh-farouk merged 1 commit from chore/include-service-livekit-in-install-all into development

2026-04-22 18:22:17 +00:00

sameh-farouk commented

2026-04-22 18:20:49 +00:00

Member

Summary

Follow-up to #115: adds service_livekit to the service_install_all list so the bulk installer builds livekit binaries alongside collab, instead of deferring them to the first service_collab start trigger.

Why

PR #115 introduced service_livekit.nu and wired service_collab start to auto-chain service_livekit start on dev boxes. But service_install_all (called by install_core --update and used during --template snapshotting) never had service_livekit in its list, so:

Fresh hosts / fresh templates didn't get livekit binaries prebuilt.
First service_collab start would trigger service_livekit install under the hood → an unexpected ~2-minute cargo build mid-operation.
Template snapshots never included livekit binaries; new users always paid the first-start build cost.

Adding livekit to the list fixes all three.

Shape

Two lines added to tools/modules/services/packages.nu:

use service_livekit.nu at the top alongside the other service imports.
{name: "service_livekit", run: ...} entry in services_extra, placed immediately after service_collab since the two are paired (collab chains livekit at start-time).

No re-ordering of existing entries; no behavior change for any existing service.

Testing

Parse check: nu -c 'use packages.nu *' clean.
Manual verification: service_install_all --core is unaffected (livekit only lives in services_extra). service_install_all (full run) now builds livekit.

Scope

Intentionally small: one commit, two lines. No behavior changes for install order, dependency resolution, or any existing service. Merges cleanly into development.

## Summary Follow-up to #115: adds `service_livekit` to the `service_install_all` list so the bulk installer builds livekit binaries alongside collab, instead of deferring them to the first `service_collab start` trigger. ## Why PR #115 introduced `service_livekit.nu` and wired `service_collab start` to auto-chain `service_livekit start` on dev boxes. But `service_install_all` (called by `install_core --update` and used during `--template` snapshotting) never had `service_livekit` in its list, so: - Fresh hosts / fresh templates didn't get livekit binaries prebuilt. - First `service_collab start` would trigger `service_livekit install` under the hood → an unexpected ~2-minute cargo build mid-operation. - Template snapshots never included livekit binaries; new users always paid the first-start build cost. Adding livekit to the list fixes all three. ## Shape Two lines added to `tools/modules/services/packages.nu`: 1. `use service_livekit.nu` at the top alongside the other service imports. 2. `{name: "service_livekit", run: ...}` entry in `services_extra`, placed immediately after `service_collab` since the two are paired (collab chains livekit at start-time). No re-ordering of existing entries; no behavior change for any existing service. ## Testing - Parse check: `nu -c 'use packages.nu *'` clean. - Manual verification: `service_install_all --core` is unaffected (livekit only lives in `services_extra`). `service_install_all` (full run) now builds livekit. ## Scope Intentionally small: one commit, two lines. No behavior changes for install order, dependency resolution, or any existing service. Merges cleanly into `development`.

sameh-farouk added 1 commit

2026-04-22 18:20:49 +00:00

chore(packages): include service_livekit in service_install_all 501823b1dd

Followup to PR #115 (which introduced the service_livekit module). The
bulk installer now builds livekit binaries alongside collab, so
`service_install_all --update` on a fresh host prebuilds everything
instead of deferring livekit's cargo build until the first
`service_collab start` triggers it via the dev-box auto-chain.

Placed next to service_collab since the two are paired: collab chains
livekit at start-time; install-time ordering is independent but keeping
them adjacent in the list makes the relationship obvious in the output.