About extension and plugin && compatibility with pi-mono

[Parsifa1]

Question

I've been testing some plugins from pi-mono lately and found that most of their own extension interfaces are the same as those of omp, and with the help of bun most of the plugins probably work straight away (not sure).

But there seems to be some schema inconsistency that causes omp plugin install xxx to be unavailable, as evidenced by:

"pi/omp": {
    extensions: [],
}

This is what pi-mono needs, but our plugin system doesn't implement this key, so I guess it shouldn't be too complicated to work on? If I have time I can think about implementing it.

---

There's also a small issue with extension:
#413

This issue made me realize that I've had a previous attempt to use tui to disable plugins that didn't work, I've investigated the entire codebase and made a simple draft and it seems that the disabledExtensions result doesn't connect to the actual capability in the end, is this intentional or is it just not implemented yet? I'm also interested in trying to finalize it when I have time.

Context

As the most prestigious pi-mono fork, I think it's great to maintain compatibility with its own ecosystem, what do you think?

Topic

Extensions

Platform

None

[Parsifa1]

don't know what do you think of it, thanks anyway 😉

I think there should also be a guide for plugin developers , there are almost no doc for it,i greped some data on npm, realised it maybe the old standard before oh-my-pi become a complete fork?

[Parsifa1]

oh, i see 6a0488a, now we have extensions?
ref to https://github.com/badlogic/pi-mono/blob/main/packages/coding-agent/docs/packages.md#creating-a-pi-package

maybe also skills and prompt?

---

by the way, now omp plugin install git:github.com/xxx will failed, because:

oh-my-pi/packages/coding-agent/src/extensibility/plugins/manager.ts

Line 30 in 6c296bf

const VALID_PACKAGE_NAME = /^(@[a-z0-9-~][a-z0-9-._~]*\/)?[a-z0-9-~][a-z0-9-._~]*(@[a-z0-9-._^~>=<]+)?$/i;

maybe also allow github url?

[sodie2323]

I am confused. what's the difference between extensions and plugins?

[joshmeads]

I agree this is rather frustrating. I assumed it would work with the Pi ecosystem considering it's a fork and the projects name still contains Pi. Granted I started using it today, but the naming schema would lead users to believe they're tightly related.

eg pi install npm:<name>. Even if it was omp install npm:<name> as long as it could work with published plugins that would be the ideal.

I half got around it by using pi install -l npm:name and then cp -r .pi/npm ~/.omp/plugins though be warned this is a 3:30am hack. If I spot a cleaner approach tomorrow I'll update.

[roboomp]

Both concrete technical claims are already implemented in main: the plugin manifest is read from the package.json pi/omp field and supports the extensions[] key, and disabledExtensions is wired into capability loading by filtering items by extension id. Only the broad open-ended pi-mono ecosystem-compatibility discussion remains.

Evidence: Manifest: installer.ts:78/123 and manager.ts:282/449 read pkg.omp || pkg.pi; PluginManifest.extensions?: string[] at extensibility/plugins/types.ts:40; loader.ts resolvePluginPaths handles the 'extensions' key (line 174). disabledExtensions->capability: capability/index.ts:110-155 builds disabledExtensionIds and skips items via capability.toExtensionId (line 152-154); set/read in modes/components/extensions/extension-dashboard.ts:225-236 and state-manager.ts isDisabled checks. coding-agent CHANGELOG lines 3604-3611 document toExtensionId + disabledExtensions capability support.

This looks resolved in main (v15.10.2), so closing during a stale-issue sweep. Please reopen if a specific part is still outstanding.