Split Gate into minimal standalone package (KaimonGate.jl)

kahliburke commented

2026-04-07 10:14:14 -07:00

(Migrated from github.com)

Context

Kaimon.jl has ~120 transitive dependencies (HTTP server, Qdrant client, JSON3, Documenter, SQLite, etc.) because it bundles the MCP server, TUI dashboard, indexing, and REPL gate into a single package. Users who only want the gate (Gate.serve()) to connect their REPL to Kaimon must either install the full Kaimon in their global environment, pulling in all those deps and risking version conflicts, or add Kaimon as a dep to every project that needs the gate.

The root issue was raised in #19 — JSON 1.5 (required by Kaimon) conflicts with packages still on JSON 0.21 (WebIO.jl and 30+ others). ShareAdd.jl helps with `Project.toml` pollution but can't solve runtime conflicts since Julia only loads one version of a package per session.

Proposal

Extract `src/gate.jl` into a standalone `KaimonGate.jl` package with a minimal dependency surface:

Required: ZMQ.jl
Stdlib: REPL, Serialization, Dates, TOML

That's it. No HTTP, no JSON3, no Qdrant, no Documenter. Users who only want the REPL-side gate install `KaimonGate.jl` instead of full `Kaimon.jl`. The TUI/MCP server (`Kaimon.jl`) depends on `KaimonGate.jl` for the protocol and socket types.

Scope

Move `src/gate.jl` to a new package `KaimonGate.jl` in the same repo (monorepo) or a separate repo
Export the public Gate API: `serve()`, `stash()`, `progress()`, `is_cancelled()`, `call_tool()`, `list_tools()`, `push_panel()`, `GateTool`, `restart()`, `shutdown()`
Update `Kaimon.jl` to use `KaimonGate` as a dep instead of bundling
Update docs: installation instructions mention `KaimonGate` for users who only want the protocol piece
Update extension bootstrap script to use `KaimonGate` instead of full Kaimon
Consider: should extensions use `KaimonGate` directly so they don't pull in the full Kaimon when loaded by the MCP server?

Open questions

Monorepo (subdirectory with own Project.toml) vs separate repo
Name: `KaimonGate.jl` vs `REPLGate.jl` vs something else
Should the extension API (push_panel, GateTool) live in KaimonGate or Kaimon?
Migration path for existing users with `using Kaimon; Gate.serve()` in startup.jl

## Context Kaimon.jl has ~120 transitive dependencies (HTTP server, Qdrant client, JSON3, Documenter, SQLite, etc.) because it bundles the MCP server, TUI dashboard, indexing, and REPL gate into a single package. Users who only want the gate (`Gate.serve()`) to connect their REPL to Kaimon must either install the full Kaimon in their global environment, pulling in all those deps and risking version conflicts, or add Kaimon as a dep to every project that needs the gate. The root issue was raised in #19 — JSON 1.5 (required by Kaimon) conflicts with packages still on JSON 0.21 (WebIO.jl and 30+ others). ShareAdd.jl helps with \`Project.toml\` pollution but can't solve runtime conflicts since Julia only loads one version of a package per session. ## Proposal Extract \`src/gate.jl\` into a standalone \`KaimonGate.jl\` package with a minimal dependency surface: - **Required**: ZMQ.jl - **Stdlib**: REPL, Serialization, Dates, TOML That's it. No HTTP, no JSON3, no Qdrant, no Documenter. Users who only want the REPL-side gate install \`KaimonGate.jl\` instead of full \`Kaimon.jl\`. The TUI/MCP server (\`Kaimon.jl\`) depends on \`KaimonGate.jl\` for the protocol and socket types. ## Scope - Move \`src/gate.jl\` to a new package \`KaimonGate.jl\` in the same repo (monorepo) or a separate repo - Export the public Gate API: \`serve()\`, \`stash()\`, \`progress()\`, \`is_cancelled()\`, \`call_tool()\`, \`list_tools()\`, \`push_panel()\`, \`GateTool\`, \`restart()\`, \`shutdown()\` - Update \`Kaimon.jl\` to use \`KaimonGate\` as a dep instead of bundling - Update docs: installation instructions mention \`KaimonGate\` for users who only want the protocol piece - Update extension bootstrap script to use \`KaimonGate\` instead of full Kaimon - Consider: should extensions use \`KaimonGate\` directly so they don't pull in the full Kaimon when loaded by the MCP server? ## Open questions - Monorepo (subdirectory with own Project.toml) vs separate repo - Name: \`KaimonGate.jl\` vs \`REPLGate.jl\` vs something else - Should the extension API (push_panel, GateTool) live in KaimonGate or Kaimon? - Migration path for existing users with \`using Kaimon; Gate.serve()\` in startup.jl

👍 3

haakon-e commented

2026-04-08 12:08:04 -07:00

(Migrated from github.com)

I have Kaimon added as a Julia app, and launch the dashboard from terminal with kaimon.
I also have Kaimon in my global env and using Kaimon; Gate.serve() in my startup.jl.

With this proposed change, I would still have Kaimon.jl installed as a Julia app, but only KaimonGate.jl installed in the global environment.

Q: Is there any functionality from Kaimon.jl, besides the Gate module, that I (as a user) need to access from the global environment?

If no, then I support this change. It would probably address the issue I had in https://github.com/kahliburke/Kaimon.jl/issues/15#issuecomment-4128159073, in which Kaimon and JuliaFormatter couldn't be installed in the same environment.

I have Kaimon added as a Julia app, and launch the dashboard from terminal with `kaimon`. I also have Kaimon in my global env and `using Kaimon; Gate.serve()` in my `startup.jl`. With this proposed change, I would still have `Kaimon.jl` installed as a Julia app, but only `KaimonGate.jl` installed in the global environment. **Q:** Is there any functionality from `Kaimon.jl`, besides the Gate module, that I (as a user) need to access from the global environment? If no, then I support this change. It would probably address the issue I had in https://github.com/kahliburke/Kaimon.jl/issues/15#issuecomment-4128159073, in which Kaimon and JuliaFormatter couldn't be installed in the same environment.

❤️ 1

ffevotte commented

2026-04-14 02:18:24 -07:00

(Migrated from github.com)

I like this proposal, thanks!

My 2 cents on (some of) your open questions: if it were me, I'd go for a monorepo, and the name "KaimonGate.jl".

And another question: if Kaimon.jl depends on KaimonGate.jl for the protocol implementation, would that raise (in)compatibility issues in case the TUI/MCP server and the Gate are installed in different versions? I could see that as a potential source of problems in the medium/long run when users will want to upgrade Kaimon and/or KaimonGate to benefit from newer versions.

I like this proposal, thanks! My 2 cents on (some of) your open questions: if it were me, I'd go for a monorepo, and the name "KaimonGate.jl". And another question: if Kaimon.jl depends on KaimonGate.jl for the protocol implementation, would that raise (in)compatibility issues in case the TUI/MCP server and the Gate are installed in different versions? I could see that as a potential source of problems in the medium/long run when users will want to upgrade Kaimon and/or KaimonGate to benefit from newer versions.

❤️ 1

kahliburke commented

2026-04-14 21:16:43 -07:00

(Migrated from github.com)

@ffevotte I would add a version compatibility check, but good observation.

It's something I'll probably tackle soon-ish.

@ffevotte I would add a version compatibility check, but good observation. It's something I'll probably tackle soon-ish.

kahliburke commented

2026-06-08 23:20:08 -07:00

(Migrated from github.com)

Update here, this work is essentially done and will be present in 2.0.0 to be released in the near future.

👍 1 🚀 1

kahliburke commented

2026-06-16 04:25:41 -07:00

(Migrated from github.com)

Done in 2.0 — KaimonGate is now a standalone package (lib/KaimonGate) with a minimal dependency set, so the gate runs without pulling in the full Kaimon stack. Shipping in 2.0.

👍 1

Rows
Columns

Split Gate into minimal standalone package (KaimonGate.jl) #20

Context

Proposal

Scope

Open questions