- The rewrite keeps dependencies thin: everything you need to run the stack, nothing you do not. - Aside from git-daemon, the usual suspects are PyGit2 for fast repo work, FastAPI and Uvicorn for the ASGI surface, - Jinja2 for templates, orjson for JSON, pydantic-settings for configuration, and python-ripgrep for search. + The goal of PyGitWeb is to provide everything you need to self host a code forge for small or medium-sized teams. + PyGitWeb implements OAuth2 flows, but if running locally or inside a LAN, it can be run without authentication.
PyGit2 is the only dependency required by the internal tooling package, so you can script workflows without - bringing up the web server. There is also a plugin model if you want to extend the stack with your own tools. + bringing up the web server. There is also an ABC-based plugin model if you want to extend the stack with your own tools.
-We believe all project metadata should live in-situ... discovering new merge requests and tasks should be a git fetch.
+All project metadata is stored in-situ; discovering new merge requests and tasks is just a git fetch.
- Settings, merge requests, comments, Kanban tasks: it all lives in your repository object database. + Settings, merge requests, comments, and tasks all live in your repository object database. No separate database service to provision. If you have a repo, you have what PyGitWeb needs.
Setup is easy - give it a try.
@@ -106,7 +105,7 @@- Not yet - stay tuned for updates! + Not yet. PyGitWeb is currently only tested with light workflows, and is only recommended for evaluation by individuals and small teams. Stay tuned for updates!