在Pyodide Worker与JupyterLite主线程间构建RPC的正确抽象选型

不用AnyWidget这类可视化组件，直接基于Jupyter的Comm机制注册自定义Comm Target是最精准的选择——这完全是纯通信层的逻辑，不需要绑定任何UI元素，刚好匹配你从Pyodide Worker调用主线程GM函数的需求。

JupyterLite端注册自定义Comm Target的代码示例 #

1. 主线程（Tampermonkey脚本/页面侧）代码 #

负责注册Comm Target，处理Pyodide Worker的RPC请求，调用window.GM并返回结果：

// 在主线程（Tampermonkey环境）中注册Comm Target
define([
  '@jupyterlab/coreutils',
  '@jupyterlab/services'
], function(coreutils, services) {
  // 注册名为'gm_rpc'的Comm Target
  services.CommManager.registerTarget('gm_rpc', function(comm, msg) {
    // 监听来自Pyodide的RPC请求
    comm.onMsg(function(msg) {
      const { method, args } = msg.content.data;
      // 调用对应的GM函数
      const result = window[`GM_${method}`](...args);
      // 将结果返回给Pyodide
      comm.send({ result: result });
    });

    // 可选：处理Comm关闭事件
    comm.onClose(function(msg) {
      console.log('GM RPC Comm closed');
    });
  });

  // 导出扩展
  return {
    id: 'tampermonkey-gm-rpc:plugin',
    autoStart: true,
    activate: function(app) {
      console.log('Tampermonkey GM RPC extension activated');
    }
  };
});

2. Pyodide Worker（Python侧）代码 #

负责创建Comm连接，发起RPC调用主线程的GM函数：

from ipykernel.comm import Comm

# 创建与主线程'gm_rpc'目标的Comm连接
gm_comm = Comm(target_name='gm_rpc')

def call_gm_method(method, *args):
    # 发送RPC请求
    gm_comm.send({'method': method, 'args': args})
    # 等待并返回结果（简化实现，实际可通过异步回调优化）
    def handle_reply(msg):
        return msg['content']['data']['result']
    return gm_comm.on_msg(handle_reply)

# 示例：调用GM_setValue
call_gm_method('setValue', 'test_key', 'test_value')

3. 扩展配置（jupyter-lite.json） #

需要在JupyterLite配置中添加该扩展，确保加载生效：

{
  "jupyter-lite-schema-version": 0,
  "jupyter-config-data": {
    "extensions": {
      "tampermonkey-gm-rpc:plugin": true
    }
  }
}

为什么这比AnyWidget更合适 #

• 完全剥离UI依赖：AnyWidget核心是构建交互式可视化组件，你的场景不需要任何UI，纯通信逻辑用Comm Target扩展更贴合。
• 符合Jupyter生态规范：Comm机制是Jupyter内核与前端通信的标准方式，用这种方式实现RPC更稳定，也更容易和现有Pyodide/JupyterLite生态集成。

内容的提问来源于stack exchange，提问作者Ryan Nowakowski