Consider delegating the packaging layer to microsoft/apm

[vlsi]

What should happen

Prototype APM as the packaging layer behind the existing /magpie-setup entry point. Keep /magpie-setup as the guided wrapper, but let it call apm install for fetch, lock, deploy, and namespacing instead of the bespoke snapshot-and-symlink machinery.

In scope (APM would subsume)

• Snapshot fetch and the two lock files
• Multi-target deploy and magpie- namespacing
• Family opt-in (maps onto --skill / sub-packages; splitting into separate packages is not required)
• Drift detection

Why

setup reimplements most of a package manager by hand: a committed pin (.apache-magpie.lock), a per-machine lock, a gitignored snapshot (.apache-magpie/), multi-target deploy through a canonical .agents/skills/ plus relay symlinks, magpie- namespacing, version pinning, and drift detection. [microsoft/apm](https://github.com/microsoft/apm) already provides all of that: apm.yml + content-hashed apm.lock.yaml, native deploy to eight agents (Claude, Copilot, Cursor, Codex, Gemini, Windsurf, Kiro, OpenCode), git-ref/tag pinning, and per-skill selection (apm install … --skill <name>). Carrying our own resolver may be a cost we do not need.

Which layer

Other / unsure

Boundary conditions (optional)

No response

Out of scope (optional)

• Secure-agent setup (sandbox, clean-env wrapper, pinned tools)
• post-checkout hook and worktree propagation
• Agentic overrides: the protocol is plain text in each SKILL.md, and override files live in the adopter's own .apache-magpie-overrides/, which apm install never touches

References (optional)

• https://github.com/microsoft/apm

[potiuk]

interesting idea - but it will have to be carefully checked - while we are doing this now mostly from main - we have other ways of installation:

a) as plugins
b) from SVN
c) Magpie adopts itself from local installation

So while APM might simplify some parts, it also might add coupling which will make other installation methods more difficult - and the secure setup, post-checkout and worktree propagation, also skill overrides reconciliation and drift detection, and particularly upstreaming changes are essential part of Magpie.

POC would be useful to show how all those might work.

[vlsi]

Sure. Take your time.
As far as I can see, Magpie hardcodes for Apache projects, so I don't think I would use it in the nearest future (Magpie looks like an overkill for JMeter / Calcite).

particularly upstreaming changes

I've recently asked for apm find feature microsoft/apm#1156 for exactly the use case of upstreaming the skill changes.

secure setup, drift detection are there in apm.
"post-checkout" are known source of CVEs in Python/npm, so I would avoid "post-checkout" steps in package managers.

This is just to let your know, not pushing.
Sure you might get better picture by pointing your agent at apm repository.

[potiuk]

As far as I can see, Magpie hardcodes for Apache projects, so I don't think I would use it in the nearest future (Magpie looks like an overkill for JMeter / Calcite).

Nope - we have Apache stuff extracted to separate skills)

Sure. Take your time.

BTW. The POC was proposal mainly for you ... you could make a POC - and we can review and accept if it will work :)