Clojurians Log v2

Why not use Polylith? because of bb requirement?

Oh, because I didn't make NIH research, it seems. I didn't know polylith had these functionalities. Basically, created the script that was useful to me, working on monorepo directories. Then shared. Didn't think too much (because I didn't find a tool that would do this)

Nice script :). Btw, anyone here using Polylith and how is it?

@pedrogbranquinho thats fair. I’ve not used Polylith yet to know the features/tradeoffs intimately. But the monorepo flexibility is enticing. I’ve been looking to refactor my sprawly codebase into Polylith, hopefully to make deployments more flexible. I am also interesting in trying out Hive. Do you sense a conflict? afaik, Polylith requires buy-in to using their command line tool, to merge segments of a repo for repl and deployment. https://polylith.gitbook.io/polylith/introduction/polylith-in-a-nutshell

This one outlines some of the considerations of sharing code. https://polylith.gitbook.io/polylith/introduction/sharing-code

I don't see any conflict! I'm trying to modularize hive as much as I can. Currently working out on decoupling Emacs itself, to be an optional backend, as well as supporting multiple headed agentic-terminals aside claude code, for subagents. So, in the long term, I will adopt some strategy for distributing and registering Addons. For now, you have to clone everything you want, like https://github.com/hive-agi/basic-tools-mcp (read, write, grep, glob stuff), https://github.com/hive-agi/scc-mcp for cyclomatic complexity analysis etc, https://github.com/hive-agi/clj-kondo-mcp, https://github.com/hive-agi/lsp-mcp, etc... Here you could add https://github.com/hive-agi/hive-mcp/wiki/Creating-Addons. Feel free to write anyone you want, maybe wrapping polylith? A nice exercise. That way you don't have to touch hive-mcp's core to extend it. What is still coupled to hive-mcp's core memory , kg ,`kanban` and workflow being the core tools that differentiate programming with hive-mcp. kanban and workflow may get decoupled. And, at that point, I may go with writing up something for the registry (for easy addon management)... So, currently you clone things locally, and in your deps.local.edn :

{:extra-paths ["test"]
 :deps
 {io.github.hive-agi/lsp-mcp {:local/root "../lsp-mcp"}
  io.github.hive-agi/basic-tools-mcp {:local/root "../basic-tools-mcp"}
  io.github.hive-agi/clj-kondo-mcp {:local/root "../clj-kondo-mcp"}
  io.github.hive-agi/scc-mcp {:local/root "../scc-mcp"}
  io.github.hive-agi/hive-claude {:local/root "../hive-claude"}
  io.github.hive-agi/vterm-mcp {:local/root "../vterm-mcp"}}}

cd $HIVE_MCP_DIR
clojure -Sdeps "$(cat deps.local.edn)" -X:mcp:dev

"mcpServers": {
    "hive": {
      "type": "stdio",
      "command": "/path/to/bb-mcp/start-bb-mcp.sh",
      "args": [],
      "env": {}
    }

Oh, yeah, it has also native cider, clojure_nrepl and support for a bunch of things (`magit` etc). But, core features is as stated. Play around with memories and kg, workflow wrap and workflow catchup . Every time you are close to the end of context window. Tell llm to "make memories on what learned that session, kg connect then and wrap". Then, start new session and tell run workflow catchup and kg traverse from last session's memory. This way you have session continuity. Memory that persist, scoped, and organizable through kg . Knowledge accumulation. The more you use, the better the tool becomes. kanban are regular memories. So, you also can link them, just like regular memories.