Files

T

tao.chen c919c95842 Initial commit: opencode_bridge JupyterLab extension (Slices 1-3.5)

A JupyterLab extension that bridges the cell UI to a local OpenCode Serve
process. The extension is a dual package: a Python server extension
exposed under /opencode-bridge/*, plus a TypeScript frontend that
registers per-cell toolbars.

Backend (Python, tornado)
- Slice 1: config + auth + OpenCode HTTP client (tornado.httpclient,
  no aiohttp). 4 settings in schema/plugin.json (url, user, password,
  request timeout).
- Slice 2: handlers for /hello, /health, /providers, /edit.
- Slice 2.1 (correction): SessionManager with 1 notebook = 1 session
  mapping, async-safe via per-path locks, 404 recovery via invalidate().
  Two new endpoints: GET /sessions, DELETE /session?notebook=<path>.
- 32 pytest tests pass.

Frontend (TypeScript, JupyterLab 4.6)
- src/types.ts: CellContext, OpenCodeRequest/Response, OpenCodeSettings.
- src/context/cell_context.ts: extract CellContext from a CodeCell +
  its parent NotebookPanel, structured error collection.
- src/api/opencode_client.ts: callOpenCodeEdit, callOpenCodeProviders.
- src/components/opencode_cell_footer.ts: OpenCodeCellFooter Widget
  implementing ICellFooter with 3 buttons (optimize / fix / edit),
  resolved via this.parent instanceof CodeCell. NOT cellToolbar
  (does not exist in JL 4.6) and NOT Widget.findParent (removed in
  @lumino/widgets 2.x).
- src/components/opencode_cell_factory.ts: Cell.ContentFactory
  subclass returning the OpenCodeCellFooter.
- src/components/opencode_installer.ts: installOpenCodeEverywhere
  patches every notebook (existing + new) to use the custom factory.
- src/index.ts: registers the factory, loads settings, fetches
  /providers on activation and logs the list to the console.
- 23 jest tests pass (mocked JupyterLab boundary, pnpm path safe).

Settings
- 6 fields: 3 auth (url/user/password) + 1 timeout + 2 model selection
  (provider/model). Provider list is fetched at startup from
  /opencode-bridge/providers and printed to the browser console so
  users can copy values into Settings Editor.

Docs
- design.md: 6 sections covering architecture, UI flow, API contract,
  TS skeletons, session management (v0.2.1 correction), and
  provider/model selection (v0.2.2 addition).
- CLAUDE.md: agent guidance for working in this repo.
- TODO.md: remaining work for Slices 4-7 + v0.4+ backlog.

CI
- Gitea release workflow at .github/workflows/build.yml.
- Bark notification helper (non-fatal on failure).

Generated artefacts ignored: opencode_bridge/labextension/, _version.py,
*.tsbuildinfo, junit.xml, test.ipynb scratch notebook.

2026-07-22 19:07:58 +08:00

2.7 KiB

Raw Blame History

Making a new release of opencode_bridge

The extension can be published to PyPI and npm manually or using the Jupyter Releaser.

Manual release

Python package

This extension can be distributed as Python packages. All of the Python packaging instructions are in the pyproject.toml file to wrap your extension in a Python package. Before generating a package, you first need to install some tools:

pip install build twine hatch

Bump the version using hatch. By default this will create a tag. See the docs on hatch-nodejs-version for details.

hatch version <new-version>

Make sure to clean up all the development files before building the package:

jlpm clean:all

You could also clean up the local git repository:

git clean -dfX

To create a Python source package (.tar.gz) and the binary package (.whl) in the dist/ directory, do:

python -m build

python setup.py sdist bdist_wheel is deprecated and will not work for this package.

Then to upload the package to PyPI, do:

twine upload dist/*

NPM package

To publish the frontend part of the extension as a NPM package, do:

npm login
npm publish --access public

Automated releases with the Jupyter Releaser

The extension repository should already be compatible with the Jupyter Releaser. But the GitHub repository and the package managers need to be properly set up. Please follow the instructions of the Jupyter Releaser checklist.

For the release workflows in this repository, make sure GitHub is configured with:

a release environment
an APP_PRIVATE_KEY secret
an APP_ID repository variable

When using npm trusted publishing, NPM_TOKEN is not required (and trusted publishing is recommended). Configure NPM_TOKEN only if you are publishing without trusted publishers.

Here is a summary of the steps to cut a new release:

Go to the Actions panel
Run the "Step 1: Prep Release" workflow
Check the draft changelog
Run the "Step 2: Publish Release" workflow

Note

Check out the workflow documentation for more information.

Publishing to `conda-forge`

If the package is not on conda forge yet, check the documentation to learn how to add it: https://conda-forge.org/docs/maintainer/adding_pkgs.html

Otherwise a bot should pick up the new version publish to PyPI, and open a new PR on the feedstock repository automatically.

2.7 KiB Raw Blame History