Make scripts/linux/setup.sh and its Windows peer support pick-and-choose tool installation -- some users want a subset, not the full set.
Why now
Two new tools are queued (delta, lazygit) and the existing scripts/linux/tools/ directory already implies a tools-as-modules pattern. Adding a flag/manifest framework first means new tools (#TBD-delta, #TBD-lazygit) slot in cleanly instead of being bolted on and refactored later.
Open design questions (go:needs-research)
The team should grill these before implementation. Three credible shapes:
| Shape |
Pros |
Cons |
Flags -- setup.sh --only=delta,lazygit / --skip=copilot-cli |
Script-friendly, CI-friendly, terse |
Discovery is poor; users must know tool names |
Interactive prompt -- check-boxes via select / Out-GridView |
Best UX for humans |
Breaks CI/headless; needs a --non-interactive escape hatch |
Manifest file -- tools.manifest opt-in/opt-out file in repo or ~/.config/ |
Reproducible, version-controllable |
Indirection; harder to discover than flags |
| Hybrid (likely answer) -- flags for CI, prompt for humans, manifest for reproducibility |
Covers all three audiences |
Most surface area to design and test |
Required outcomes (whatever shape wins)
- All existing tool installers in
scripts/linux/tools/ and scripts/windows/tools/ remain individually invocable
- Default behavior (no flags) MUST match current behavior -- backward compatibility gate
- A
--list / --help mode that enumerates available tools
- New tests (bash + pwsh parity) covering: default install,
--only subset, --skip subset, unknown-tool error
- Documentation update in README and
scripts/linux/setup.sh --help
Routing
squad:goofy (cross-platform: bash + pwsh parity is the core constraint)
squad:mickey (Lead -- architectural decision on flags vs interactive vs manifest)
go:needs-research until the shape decision is grilled and recorded in decisions.md
Make
scripts/linux/setup.shand its Windows peer support pick-and-choose tool installation -- some users want a subset, not the full set.Why now
Two new tools are queued (delta, lazygit) and the existing
scripts/linux/tools/directory already implies a tools-as-modules pattern. Adding a flag/manifest framework first means new tools (#TBD-delta, #TBD-lazygit) slot in cleanly instead of being bolted on and refactored later.Open design questions (
go:needs-research)The team should grill these before implementation. Three credible shapes:
setup.sh --only=delta,lazygit/--skip=copilot-cliselect/Out-GridView--non-interactiveescape hatchtools.manifestopt-in/opt-out file in repo or~/.config/Required outcomes (whatever shape wins)
scripts/linux/tools/andscripts/windows/tools/remain individually invocable--list/--helpmode that enumerates available tools--onlysubset,--skipsubset, unknown-tool errorscripts/linux/setup.sh--helpRouting
squad:goofy(cross-platform: bash + pwsh parity is the core constraint)squad:mickey(Lead -- architectural decision on flags vs interactive vs manifest)go:needs-researchuntil the shape decision is grilled and recorded indecisions.md