✨ [Enhancement] Adopt uv workspace for local monorepo development (graphiti-core, mcp_server, server)
🗂️ Background
Currently, the graphiti project is split into multiple subprojects (graphiti_core, mcp_server, server), but there is no workspace configuration.
This forces local development to rely on hardcoded file:// paths or manual pip install -e ...
✅ What I expected
- A proper uv workspace or poetry workspace at the repo root.
- All submodules should declare
[tool.uv.sources]withworkspace = truefor local modules. - Local
graphiti_corechanges should automatically propagate tomcp_serverandserverwithout needing repeated reinstalls.
⚡ What actually happens
- Local development requires hardcoding absolute
file://paths to the localgraphiti-corein eachpyproject.toml. - This breaks PEP 508 compliance if the path is not portable across machines.
- Developers have to run
uv sync --reinstallfrequently to fix mismatched builds.
🧩 Proposed solution
Add a workspace definition at the repo root:
[tool.uv.workspace]
members = [".", "mcp_server", "server"]
In each member’s pyproject.toml, declare:
[tool.uv.sources]
graphiti-core = { workspace = true }
Document this in README.md or CONTRIBUTING.md.
🙌 Benefits
- Zero hardcoding.
- Faster dev iteration.
- Fully PEP 508-compliant.
- Better DX for new contributors.
✨ Extra context
I tested this locally and confirmed:
- uv sync correctly resolves the local core package.
- mcp_server and server immediately see code changes in graphiti_core.
- No more Failed to generate package metadata errors.
Happy to send a PR if you want! Just let me know if you prefer uv workspace or poetry workspace. 🫶
I agree...how do we get more support on this recommendation?
@MumuTW Is this still relevant? Please confirm within 14 days or this issue will be closed.
@MumuTW Is this still an issue? Please confirm within 14 days or this issue will be closed.
@MumuTW Is this still relevant? Please confirm within 14 days or this issue will be closed.