Pipecat 社羣插件修復 PR 提交一個月後仍無一合併

A few weeks ago I published a count: of the community plugins listed in Pipecat's docs, 18 of 56 didn't work. Broken imports, missing dependencies, version pins dragging Pipecat backwards a year.

I also said I'd send PRs for the ones I could fix from outside, and I did — eleven of them, across eleven repositories.

Here is what has happened since. It is not the post I expected to write, and the most useful part came from a reader rather than from me.

The eleven PRs

Every one is still open. Every one is mergeable, not a draft, with no conflicts and nothing red.

29d  ImportError on pipecat >= 1.8        no response
29d  ImportError on pipecat >= 1.8        no response
28d  ImportError on pipecat >= 1.8        1 comment
28d  ImportError on pipecat >= 1.8        no response
28d  ImportError on pipecat >= 1.8        no response
28d  ImportError on pipecat >= 1.8        no response
28d  accept 1.11 patch releases           no response
28d  ImportError on pipecat >= 1.8        no response
22d  InterruptionFrame rename             1 review
22d  LLM context frames removed in 1.8    no response
16d  allow 1.11 and 1.12                  no response

Nine of eleven have had no human response at all. Nothing has merged.

I want to be careful about what that does and doesn't mean. A community plugin is usually one engineer inside a vendor, with a roadmap that isn't this. An unreviewed PR from a stranger is one of the easiest things in the world to not get to, and none of these repositories owes me anything. I'm reporting the number because the number is the finding, not because anybody behaved badly.

Then a reader checked my arithmetic

Arhan Canli commented on the first post within a few hours, and he was right about something I'd got wrong:

The pinned five are the only group where nothing has been shown to be broken. A plugin pinned to ==1.8.1 fails to resolve, but it may run fine on 1.12.

My headline number lumped together plugins that fail and plugins that merely won't resolve. Those are completely different messages to send a maintainer: one says "your plugin is broken", the other says "loosen a version range."

He also handed me the test:

Install the five with --no-deps next to the current pipecat-ai, then run the same import and construct step. Any that pass are "pin too tight". Any that fail are real API breaks hiding behind the pin.

So I ran it.

All five were fine

Deepdub   pinned >=0.0.97,<0.1.0   ->  compatible
Maya      pinned ==1.8.1           ->  compatible
Memcode   pinned >=1.10,<1.11      ->  compatible
Oruk      pinned >=1.8.1,<1.9      ->  compatible
Wavix     pinned ==0.0.105         ->  compatible

Every one imports and constructs against pipecat 1.12. Zero are broken. Five one-line edits to a version range would turn five red rows green, and not one of them needs a code change.

His method needed one adjustment, which is worth passing on. --no-deps also skips the plugin's own SDK, so two of the five came back unknown — not because of pipecat, but because their vendor package wasn't installed either. uv's --overrides is the sharper tool: the plugin resolves with all its real dependencies and only pipecat-ai is forced to the version under test. That's the question actually being asked, and it turned both unknowns into answers.

And a second thing I was getting wrong

Once I was looking properly, one more row didn't belong.

One plugin imports a vendor SDK that its own README says is not published to PyPI — you contact the company, get a wheel and an API key. Its packaging correctly omits the dependency, because you can't declare one that's on no index.

That plugin isn't broken. It works for that vendor's customers. It just can't be verified by a checker standing outside the licence — and listing it as "broken" next to nine plugins genuinely broken by an upstream rename put the blame in the wrong place.

It has its own status now. The checker asks PyPI whether the missing module exists at all, and only calls it gated when the answer is a definite no — a network failure leaves it broken, because reading "I couldn't ask" as "it doesn't exist" would quietly reclassify real breakage as licensing.

So the honest number

I published 18 of 56. The defensible figure was never that. Six of the plugins I called broken were working the whole time, and it took a stranger five hours to notice something I'd had weeks to check.

What I got wrong, twice

The first write-up assumed the problem was that nobody was looking. Build the checker, publish the list, send the patches, and the table should start going green.

It didn't. The information existed, the fixes sat one click away, and the count stayed flat. So the gap isn't detection and it isn't authorship — it's that a community plugin has no owner whose job it is to notice. Upstream has correctly delegated it. The vendor shipped it and moved on. The user who hits the ImportError silently picks a different vendor, which is the one signal that would prompt a fix and the one signal nobody receives.

The second thing I got wrong was subtler and more embarrassing: I built a tool to measure an ecosystem and then didn't interrogate my own categories. "Broken" was doing three jobs — actually broken, won't resolve, and licensed — and I shipped a headline number built on all three.

If you publish a measurement, someone will check it. That's the best thing that can happen to it.

Things that might close the loop

I'd rather end with open questions than a fake conclusion.

• CI against upstream main in the plugin repo. One scheduled workflow, and the break shows up as a red build where it can be fixed. The obvious answer, and almost nobody does it.
• A health badge on the docs page. Puts the signal where the user actually looks, at the cost of whoever maintains the page.
• Nothing. It's genuinely possible that a long tail of half-maintained integrations is the normal cost of a fast-moving framework, and users routing around it is the system working rather than failing.

If you maintain a plugin for any fast-moving framework, I'd like to know whether you run CI against its main, and if not, why not. My guess is "nobody asked and it wasn't obvious", which would be a very fixable reason.

The checker, the full table and the nightly results:
https://github.com/Rehansanjay/pipecat-plugin-health