Don't ask adding Kaimon to global env #19

New issue

Closed

opened 2026-04-05 13:11:21 -07:00 by Eben60 · 3 comments

Eben60 commented

2026-04-05 13:11:21 -07:00

(Migrated from github.com)

Each time I start Kaimon, it suggests adding it to the global environment. I think it would be better to suggest this just once during the package configuration, and then respect the user's decision.

Personally I think adding Kaimon.jl to the global environment is not necessarily a good thing. Kaimon depends on some 120 downstream packages, and having all of them in the global env manifest may easily lead to dependencies conflicts. Just one example: Kaimon requires JSON 1.5, whereas many important packages still depend on JSON v0.21 - e.g. WebIO.jl, and 33 more packages depending on it.

One could add Kaimon through the workspace feature, but my preferred way is by using my ShareAdd.jl package. The usage is as following:

using ShareAdd
@usingany Kaimon
Gate.serve()

Each time I start Kaimon, it suggests adding it to the global environment. I think it would be better to suggest this just once during the package configuration, and then respect the user's decision. Personally I think adding Kaimon.jl to the global environment is not necessarily a good thing. Kaimon depends on some 120 downstream packages, and having all of them in the global env manifest may easily lead to dependencies conflicts. Just one example: Kaimon requires JSON 1.5, whereas many important packages still depend on JSON v0.21 - e.g. [WebIO.jl](https://github.com/JuliaGizmos/WebIO.jl), and 33 more packages depending on it. One could add Kaimon through the `workspace` feature, but my preferred way is by using my [ShareAdd.jl](https://juliahub.com/ui/Packages/General/ShareAdd) package. The usage is as following: ``` using ShareAdd @usingany Kaimon Gate.serve() ```

❤️ 1

kahliburke commented

2026-04-06 18:40:01 -07:00

(Migrated from github.com)

@Eben60 , that's a fair request. I'll take a look at that, I'll take a look at what can be done. It's also possible that I could take some of the core functionality and create a lighter weight version of it. I really just want to be able to enable a startup script that will connect the sessions automatically.

kahliburke commented

2026-04-06 20:16:11 -07:00

(Migrated from github.com)

@Eben60 — good point on both counts. Just pushed a commit that makes the prompt dismissible: it now offers [Y/n/never] and persists a global_install_dismissed flag in ~/.config/kaimon/config.json. If you change your mind, kaimon --reset-global-prompt re-enables it. Will land in v1.2.1.

On the deeper concern about dependency bloat — you're right that ShareAdd.jl helps with Project.toml pollution but can't solve runtime version conflicts, since Julia only loads one version of a package per session. Even in a shared env, Kaimon's JSON 1.5 requirement would still clash with anything using JSON 0.21 in the same REPL.

Looking at src/gate.jl, the Gate itself is already lightweight — ZMQ + REPL + Serialization + Dates + TOML — and everything else in Kaimon is server/TUI/indexing code that the user's REPL doesn't need. I'll investigate whether splitting Gate out into a minimal standalone package (say, KaimonGate.jl) makes sense so users can install just the protocol piece in their global env without pulling in the full Kaimon dep graph. That would directly address the conflict issue rather than work around it.

@Eben60 — good point on both counts. Just pushed a commit that makes the prompt dismissible: it now offers `[Y/n/never]` and persists a `global_install_dismissed` flag in `~/.config/kaimon/config.json`. If you change your mind, `kaimon --reset-global-prompt` re-enables it. Will land in v1.2.1. On the deeper concern about dependency bloat — you're right that ShareAdd.jl helps with `Project.toml` pollution but can't solve runtime version conflicts, since Julia only loads one version of a package per session. Even in a shared env, Kaimon's JSON 1.5 requirement would still clash with anything using JSON 0.21 in the same REPL. Looking at `src/gate.jl`, the Gate itself is already lightweight — ZMQ + REPL + Serialization + Dates + TOML — and everything else in Kaimon is server/TUI/indexing code that the user's REPL doesn't need. I'll investigate whether splitting Gate out into a minimal standalone package (say, `KaimonGate.jl`) makes sense so users can install just the protocol piece in their global env without pulling in the full Kaimon dep graph. That would directly address the conflict issue rather than work around it.

👍 1

kahliburke commented

2026-04-07 08:39:41 -07:00

(Migrated from github.com)

Fixed in 65ca824 — the prompt is now dismissible. Released as part of the upcoming v1.3. Thanks for the report!

Filing a separate enhancement to track the deeper fix (splitting Gate into a minimal standalone package).

Fixed in 65ca824 — the prompt is now dismissible. Released as part of the upcoming v1.3. Thanks for the report! Filing a separate enhancement to track the deeper fix (splitting Gate into a minimal standalone package).