Add PowerShell as an Optional Tool From the Microsoft Feed

[ptr727]

What

Adds powershell to the host tools install-tools.sh manages, as the one optional member. It installs from Microsoft's apt repository, the same feed dotnet already falls back to, so no separate download step is needed (the path HomeAutomation-Config's PR #56 took with a tar.gz build).

• install-tools.sh --optional (or a stand-up's --optional tools step) now also installs pwsh.
• Naming it explicitly (install-tools.sh --install powershell) selects it regardless of --optional.
• The feed registration is extracted into a shared microsoft_feed(), used by both dotnet and powershell; dotnet's behavior is unchanged.
• --list marks it (optional), and the report notes when Microsoft's repository is not configured.
• Non-amd64 hosts get a named skip, matching dotnet.

Verified: shellcheck, prose_lint, markdownlint, and editorconfig are clean, and all 686 tests in scripts/tests pass. On a Debian 13 host the report shows powershell 7.6.5-1.deb available from packages.microsoft.com, and a default report (without --optional) omits it.

Docs

• host-setup/linux/README.md source taxonomy and the docker/node/dotnet section.
• docs/host-setup.md source paragraph and the "not in the table" sentence.

[Copilot]

Pull request overview

Adds PowerShell (pwsh) as an optional, opt-in tool managed by the Linux host-setup installer, using Microsofts apt feed (shared with the existing dotnet fallback path). Updates docs to describe the new source taxonomy and optional behavior.

Changes:

• Extend install-tools.sh with a new powershell tool (optional by default, included under --optional or when explicitly named).
• Factor Microsoft apt repo registration into a shared microsoft_feed() helper used by both dotnet and powershell.
• Update host setup documentation to mention PowerShell and its source/feed behavior.

Reviewed changes

Copilot reviewed 3 out of 3 changed files in this pull request and generated 1 comment.

File	Description
host-setup/linux/README.md	Documents PowerShell as an upstream-apt-repo sourced tool and explains its optional, opt-in status.
host-setup/linux/install-tools.sh	Implements PowerShell install/report/list behavior and shares Microsoft feed registration with dotnet.
docs/host-setup.md	Updates the host-tool sourcing narrative to include pwsh and clarifies it is not part of the default contract table.

Suppressed comments (1)

host-setup/linux/install-tools.sh:689

• microsoft_feed() always runs dpkg -i and marks the apt lists dirty, which forces an apt-get update even when Microsoft's repo is already configured. That breaks the script's stated idempotence goal (refresh only when sources change) and adds unnecessary network work on repeated runs or when both dotnet and powershell call it in one run. Add a fast-path that detects an existing microsoft-prod sources/list file and only refreshes the apt cache (without setting APT_DIRTY) when already configured.

microsoft_feed() {
    local deb="$TMP_DIR/packages-microsoft-prod.deb"
    fetch -o "$deb" "https://packages.microsoft.com/config/$DISTRO_ID/$DISTRO_VERSION/packages-microsoft-prod.deb" ||
        die "Microsoft publishes no feed for $DISTRO_ID $DISTRO_VERSION"
    run_root dpkg -i "$deb"

---

💡 Add a code-review agent skill or configure MCP servers for context-aware, tailored reviews. Learn more in the docs.

[ptr727]

Suppressed finding (1) from the round on 763209f, at host-setup/linux/install-tools.sh:689:

microsoft_feed() always runs dpkg -i and marks the apt lists dirty, which forces an apt-get update even when Microsoft's repo is already configured. That breaks the script's stated idempotence goal (refresh only when sources change) and adds unnecessary network work on repeated runs or when both dotnet and powershell call it in one run.

Fixed in 5995217. microsoft_feed now returns early when microsoft-prod.sources or microsoft-prod.list already exists, so a repeat run or a run selecting both dotnet and powershell does not re-install the deb or force an apt refresh. The one refresh a run still needs comes through the ordinary apt_refresh path, matching the script's 'refreshed only when a sources file changed' contract.

Review round: #782 (review)

[Copilot]

Pull request overview

Copilot reviewed 3 out of 3 changed files in this pull request and generated no new comments.

Suppressed comments (3)

host-setup/linux/install-tools.sh:694

• microsoft_feed() aborts the entire run when the feed URL is missing (die "Microsoft publishes no feed..."). The script's contract (and README) says install/upgrade should collect per-tool failures and continue, and making powershell selectable via --optional increases the chance that an unsupported feed turns a full tools run into a hard stop. Consider returning a non-zero status instead of exiting so the caller can record a tool failure and keep going.

    local deb="$TMP_DIR/packages-microsoft-prod.deb"
    fetch -o "$deb" "https://packages.microsoft.com/config/$DISTRO_ID/$DISTRO_VERSION/packages-microsoft-prod.deb" ||
        die "Microsoft publishes no feed for $DISTRO_ID $DISTRO_VERSION"
    run_root dpkg -i "$deb"

host-setup/linux/install-tools.sh:734

• powershell_install() calls microsoft_feed without guarding its exit status. If microsoft_feed is adjusted to return non-zero instead of exiting on an unsupported feed, this call site should handle that failure explicitly so the script does not terminate under errexit and so the tool failure can be collected.

    microsoft_feed
    apt_install powershell
}

host-setup/linux/install-tools.sh:680

• If microsoft_feed() is changed to return non-zero on failure (instead of exiting), dotnet_feed() should explicitly propagate that failure; otherwise errexit handling becomes dependent on bash's conditional-list semantics. Guarding the call also makes the intended control flow clearer.

This issue also appears on line 731 of the same file.

    fi

    microsoft_feed
}

[ptr727]

Suppressed findings (3) from the round on 5995217, all one proposal:

1. host-setup/linux/install-tools.sh:694 - microsoft_feed() aborts the whole run when the feed URL is missing, and the suggestion is to return non-zero so the caller records a tool failure and keeps going.

Declined: this is the tracked migration, not a powershell fix. Ending the run on an upstream lookup that cannot be answered is this script's current, documented behavior for its sibling tools: node_install failing to read the current LTS line, uv_install finding no build for the architecture, and dotnet_install finding no package for the distribution each end the run today. TODO.md "Decide which install-tools.sh failures are collected and which end the run" records that class, names the collection existing for it, and says changing those to return non-zero "wants its own verification on each supported distribution rather than riding along with a migration." Making microsoft_feed return non-zero would change dotnet's error handling too (finding 3), which is exactly the change that entry reserves for itself.

2. host-setup/linux/install-tools.sh:734 - powershell_install() calls microsoft_feed without guarding its exit status.

Declined: conditional on finding 1. Today microsoft_feed ends the run with die on an unsupported feed, and powershell inherits the same documented behavior as the sibling tools. The call site is guarded in the tracked migration that changes the failure mode.

3. host-setup/linux/install-tools.sh:680 - dotnet_feed() should explicitly propagate microsoft_feed's failure.

Declined: same reason as finding 1. dotnet_feed's bare call is correct while microsoft_feed's failure mode is a die; the guard belongs to the tracked change, which is verified per distribution rather than riding along here.

Review round: #782 (review)