This looks really interesting. I've been using a similar tool called spr https://github.com/spacedentist/spr for the last six or so months at work. I really like the stacked diff/PR workflow. But spr has a lot of rough edges and im on the lookout for a better alternative.
Do you happen to know how your tool compares to spr? How production-ready is it?
I had checked out SPR, but found the workflow based around reordering history via interactive rebase unintuitive & clunky. That was the motivation behind building this on my own.
I have been using this for a few months now, and it has served me well! I haven't spent much (any) time marketing it, so haven't really had any feedback from other users yet. Feel free to check it out & lmk if you have any suggestions. It's also open source, so feed free to open issue/PR on Github
We are using a similar stack. I assume your client is located in the same repo as your server? That's a no-go for us, so we're planning on using the OpenAPI spec to generate a type-safe frontend client. I kind of wish it was as easy as using the RPC middleware, though.
In cases where the client needs to stay separate, we have had a good experience with Orval[1] to generate a fully-typed @tanstack/query client from our OpenAPI spec.
I overlaid bluefin-dx [1], the developer oriented build by ublue, over my Fedora Silverblue system and it's been pretty great so far. Feels a little bloated for my taste, which is why I started my own fork [2]. The ability to change things up in a layered way (basically a Dockerfile) without risking breaking anything at the host level is really nice!
The underlying interpreter obviously still contains code for the builtins; can you think of a way you might be able to invoke them without going through the __builtins__ module?
