djrobstep
How will this project evolve?
@djrobstep, I am excited to see a project that builds on your innovation with migra, but I'd like to know a little more about how you foresee this tool evolving. In particular, I am reacting to your statement in the README that you "got a bit jaded" working on migra. Makes sense–but it would be good to hear your perspective on the hurdles you faced and how you plan to overcome them this time around. This is especially important as some of us who began using migra decide where to put our energy going forward.
The large positive response to migra was due to its simple design and clear scope, which allowed it to solve problems for many people. Tension from demanding/free-riding users arises innately from that situation. However, there are also people who are willing to put energy into tools, and successful projects must effectively use and channel that help. Bluntly, ignoring or brushing off seemingly useful pull requests (https://github.com/djrobstep/migra/pull/237) and repeated requests for information (https://github.com/djrobstep/migra/issues/226, https://github.com/djrobstep/migra/issues/245) suggests a different sort of disregard that is also damaging. Even simply signaling that you are burnt out and have to step back for a while and/or empowering another like-minded maintainer to handle some of the busywork of maintenance and feature integration, would allow others to plan a clearer path forward.
There are a number of alternative tools now that are positioning themselves with migra-inspired functionality. However, many of these have major deficiencies (weird licenses/paywalls, scope creep, missing features) and all lack clear community buy-in. But something needs to fill this space that you've carved out. I'm eager to use results as a vehicle for this functionality going forward, but I'd like to hear more about your intended scope and some advice for people who want to rely on it/contribute going forward. I'd also be interested in whether you'd consider empowering additional maintainers to spread the load, if they were aligned with your goals (many people already seem eager to help; e.g. https://github.com/PhilipWee/migra/issues/7). Transitioning from an initial innovation to a tool that can be widely adopted is a lot if thankless work, but it can be a shared load, and what you've created deserves a strategy to carry it forward.
There are a number of alternative tools now that are positioning themselves with migra-inspired functionality. However, many of these have major deficiencies
I agree, and I just want to add some context on this. Here is a popularity graph of the migra-alternatives I found about:
Migra still appears to be the most loved three years after being deprecated.
Due to its unmaintained state, I tried many of these alternatives but they didn't work for me (sqldef fails to handle pg_dumps, pgdiff fails to authenticate, apgdiff can't parse complex dumps, tusker is not an alternative since it relies on migra, pg-schema-diff diffs against migrations and not an actual schema...).
I ended up using PhilipWee's migra fork. [Edit after davenquinn's answer: I actually also had packaging issues with it.]
[Edit: added pgschema suggested by @davenquinn]
Thanks for the context @GTonehour. For my part, I just spent a while evaluating pgschema which is a newcomer that has quite a well-developed vision and growing following. However, it remains both a bit too black-box and unergonomic in certain ways. Plus its implementation in a compiled language, while theoretically useful, ends up inhibiting adaptation.
I had trouble installing both PhilipWee's migra fork and this library into a uv environment for packaging reasons. If these efforts can't align and merge, developer effort will be spread too thinly to pay much attention to these ergonomic issues.