tao.chen
c919c95842
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.
89 lines
2.7 KiB
Markdown
89 lines
2.7 KiB
Markdown
# Making a new release of opencode_bridge
|
|
|
|
The extension can be published to `PyPI` and `npm` manually or using the [Jupyter Releaser](https://github.com/jupyter-server/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:
|
|
|
|
```bash
|
|
pip install build twine hatch
|
|
```
|
|
|
|
Bump the version using `hatch`. By default this will create a tag.
|
|
See the docs on [hatch-nodejs-version](https://github.com/agoose77/hatch-nodejs-version#semver) for details.
|
|
|
|
```bash
|
|
hatch version <new-version>
|
|
```
|
|
|
|
Make sure to clean up all the development files before building the package:
|
|
|
|
```bash
|
|
jlpm clean:all
|
|
```
|
|
|
|
You could also clean up the local git repository:
|
|
|
|
```bash
|
|
git clean -dfX
|
|
```
|
|
|
|
To create a Python source package (`.tar.gz`) and the binary package (`.whl`) in the `dist/` directory, do:
|
|
|
|
```bash
|
|
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:
|
|
|
|
```bash
|
|
twine upload dist/*
|
|
```
|
|
|
|
### NPM package
|
|
|
|
To publish the frontend part of the extension as a NPM package, do:
|
|
|
|
```bash
|
|
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](https://jupyter-releaser.readthedocs.io/en/latest/how_to_guides/convert_repo_from_repo.html).
|
|
|
|
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](https://docs.npmjs.com/trusted-publishers), `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](https://jupyter-releaser.readthedocs.io/en/latest/get_started/making_release_from_repo.html)
|
|
> 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.
|