[FEATURE] making APM available via chocolatey

[Werner-Swart-83]

Is your feature request related to a problem? Please describe.
As a large enterprise we have strict governance rules, if we install software from non governed package managers we have to go through a lot of red tape as well as regular reviews to make sure these sources are secure.

Describe the solution you'd like
Making APM available on chocolatey will take away the burden of managing red-tape and reduce wasted time in meetings calming stakeholder nerves.

Describe alternatives you've considered
We are currently using the Powershell installation method as well as the Winget method both of which gets block after a while by our corporate policies because they are not coming from our managed package manager (Chocolatey).

Additional context
None.

[danielmeppiel]

Triaged under the new portability/security/governance roadmap (see #116).

Thanks for opening this Werner Swart (@Werner-Swart-83) -- enterprise distribution
through governed package managers is exactly the friction we want APM
to remove on Windows.

Triage decision

accept -- Chocolatey is a well-trodden path for Windows enterprise
distribution and is consistent with the Portable pillar (we already
ship a PyInstaller binary plus PowerShell + Winget paths). Adding a
chocolatey channel removes a concrete blocker for adopters in
governed environments.

defer-later on milestone: this is feature work rather than a patch
fix, and there is no open 0.10.0 minor in the milestone list yet.
It will land in the next minor release window.

Proposed labels

theme/portability
area/distribution
type/feature
status/accepted

Milestone

null -- promote to the next open minor (likely 0.10.0) once that
milestone exists. Tracked in the roadmap discussion.

Suggested next action

If anyone in the community has Chocolatey packaging experience and
wants to drive the initial .nuspec + auto-update template, this is
a high-leverage contribution -- comment here to claim it. Otherwise
we will scope the work alongside the next minor release.

Per-lens notes (collapsed)

DevX UX Expert -- User-Need Reviewer

choco install apm would read identically to the Winget /
PowerShell paths users already see in the install docs, with the
added benefit that Chocolatey is the default approved channel in many
governed Windows environments. Removes a concrete adoption step.

Supply Chain Security Expert -- Risk-Surface Reviewer

Touches area/distribution. Chocolatey requires a signed .nuspec
plus checksummed binary URLs -- the checksum publication has to be
deterministic and tied to the same release artifacts as the GitHub
release. The auto-update template must not introduce a parallel
download path that bypasses our existing signature / hash
verification. No new credential surface beyond a Chocolatey API key
held by the release workflow (which must live in repo secrets, never
in source).

OSS Growth Hacker -- Contributor-Tone Reviewer

Author has 2 prior interactions on microsoft/apm; treat as a
new-contributor signal. Tone should be warm, name the concrete
governance pain point back to them so they feel heard, and offer a
clear "claim this if you have packaging experience" path so the
ticket converts into either a contribution or a roadmap commitment.
The reply does that.

APM CEO -- Triage Arbiter

Chocolatey is on the strategic path for Windows enterprise adoption
-- same reasoning as Winget. No design ambiguity. Holding milestone
because the next minor is not open yet, but status/accepted
captures the commitment. Primary theme/portability.

[github-actions]

Triage decision

accept

Proposed labels

theme/portability
area/distribution
type/feature
status/accepted
priority/low
help wanted

Milestone

0.9.4

Suggested next action

Check whether the existing Scoop bucket automation (#245) or WinGet manifest workflow (#246) provides a reusable pattern for automating Chocolatey package updates on release.

Suggested issue comment

Thanks for the clear enterprise use case. Chocolatey is a legitimate gap in the Windows distribution story -- Scoop (#245) and WinGet (#246) are already being addressed, and Chocolatey serves the governance-heavy enterprise segment that cannot use those.

Accepting for the 0.9.4 milestone alongside the Windows distribution work already in flight. Priority is low since Scoop and WinGet cover most Windows installations, but Chocolatey adds value for locked-down enterprise environments where those are not approved.

This is a `help wanted` item -- if you or your team are able to contribute the Chocolatey package definition and the automated update workflow (similar to the Scoop bucket pattern in #245), that would be the fastest path to getting this shipped. The existing `build-release.yml` Windows binary artifacts are the input.

Per-lens notes (collapsed)

DevX UX Expert -- User-Need Reviewer

Enterprise users on Windows with strict governance rules cannot install APM via Scoop or WinGet because those are not approved by corporate policy. Chocolatey is the managed package manager for this segment. The request is clear, the use case is real, and it aligns with the Windows Native Support work already in flight (#244, #245, #246). The framing is a standard "add distribution channel" request well understood in the package-manager space.

Supply Chain Security Expert -- Risk-Surface Reviewer

Adding a Chocolatey distribution channel introduces supply-chain considerations: who owns the Chocolatey package? Is it microsoft-org-authored or community? Is the package signed? Chocolatey's verification and signing model differs from Scoop/WinGet. The implementing PR must address package ownership and update-signing before shipping. No theme/security upgrade needed -- these are standard distribution hygiene items analogous to the Scoop work.

OSS Growth Hacker -- Contributor-Tone Reviewer

Werner-Swart-83 has author_association: NONE -- likely first-time or low prior interaction. The reply should be warm and connect to the existing Windows distribution roadmap. The issue is legitimate and well-described. Point to the existing Scoop (#245) and WinGet (#246) tracking issues as context, and explicitly invite contribution via help wanted.

Python Architect -- Architecture Reviewer

Not activated -- adding a Chocolatey distribution channel is analogous to the existing Scoop/WinGet automation work and does not require a cross-cutting design decision before code can land.

Doc Writer -- Documentation Reviewer

If Chocolatey is added, the installation guide needs a new Windows section entry. The implementing PR should update docs/src/content/docs/ accordingly. No separate area/docs-site label is needed to keep the label count at 6; the implementing PR convention will catch it.

APM CEO -- Triage Arbiter

Accept at priority/low. Chocolatey is the right next step in the Windows distribution story after Scoop and WinGet. The help wanted label invites the author or community to contribute the package definition. 0.9.4 is the right milestone given the Windows distribution work already in flight. Supply chain hygiene (ownership, signing) must be addressed in the implementing PR.

{
  "decision": "accept",
  "decision_detail": "",
  "theme": "theme/portability",
  "areas": ["area/distribution"],
  "type": "type/feature",
  "status": "status/accepted",
  "priority": "priority/low",
  "preserved_labels": ["help wanted"],
  "milestone": "0.9.4",
  "next_action": "Check whether the existing Scoop bucket automation (#245) or WinGet manifest workflow (#246) provides a reusable pattern for automating Chocolatey package updates on release.",
  "comment_markdown": "Thanks for the clear enterprise use case. Chocolatey is a legitimate gap in the Windows distribution story -- Scoop (#245) and WinGet (#246) are already being addressed, and Chocolatey serves the governance-heavy enterprise segment that cannot use those.\n\nAccepting for 0.9.4 alongside the Windows distribution work already in flight. This is a `help wanted` item -- if you or your team can contribute the Chocolatey package definition and automated update workflow, that is the fastest path to shipping."
}

---

Triage status: agentic proposal pending human ratification.
Silence is approval. Maintainers can:

• Override any label or milestone above by editing it directly --
  human edits are authoritative and will not be reverted on
  subsequent runs.
• Re-trigger triage by applying the status/needs-triage label, or
  by removing status/triaged to enroll the issue in the next
  daily sweep.

Posted by the Triage Panel workflow. See .apm/skills/apm-triage-panel for the panel skill.

Generated by Triage Panel · ● 1.6M · ◷