Local setup in addition to centralized apm setup

[barra-jmreifenberg]

Dear community,

is there already some support or even the intent to support the following scenario:

• Team sets up a repository with apm.yml which includes some dependencies, skills, agents, whatever
• any dev pulls this and thinks "hey, I have my own dependencies which are very particular to my personal needs"
• --> dev can now setup some apm dependencies which only apply to his / her local setup and will never be committed, e.g. something like a apm.local.yaml

This could be realized of course by deploying on user level, bypassing the repo one is working in, yet again this then clutters the global context of any agent harness the user is employing.

Any thoughts on this?

Cheers,
Jakob

[Tongyi (TongyiDai)]

There are currently two supported scopes, but not the per-project personal overlay you describe:

• project scope reads the repository's apm.yml and writes project-local state;
• user scope uses ~/.apm/apm.yml via apm install --global.

The second is intentionally global, so it has exactly the context-pollution drawback you identified. I could not find an apm.local.yml-style manifest that is merged only for one checkout on current main.

I think this is a useful third scope rather than just another global-install option. The important part is not only reading an ignored local manifest; it also needs separate ownership state. Otherwise a normal team apm install/prune could delete local-only material, or a local install could rewrite the shared lockfile. A safe design would be:

1. shared apm.yml + apm.lock.yaml remain reproducible and committed;
2. ignored apm.local.yml + a separate local lock/deployment ledger add dependencies for this checkout;
3. merge order is explicit, probably shared first and local second;
4. collisions fail or require an explicit local override, rather than silently shadowing team configuration;
5. uninstall/prune operate on the selected scope only.

Until such a layer exists, --global is the built-in workaround when the dependency is genuinely useful across projects. For something needed only in this repository, I would avoid editing the shared manifest unless I am willing to keep an uncommitted patch and carefully exclude it from commits; that is workable but not a robust team workflow.

Relevant current scope docs: https://microsoft.github.io/apm/reference/cli/install/

[barra-jmreifenberg]

Thx for you answer Tongyi (@TongyiDai) and sketching out your ideas. Is this something to bring in as a feature request? I would also be willing to contribute.