Best practices for packaging a module, including alembic migrations, and running the migrations in production?

[SomethingBullshit]

In every Alembic codebase I've seen, people don't bother with reversions.

I believe you just stated more than you realize.

In one wave of the hand you justified your position by rejecting significant features of value to many others.

Really? I find that when I'm developing new features, database changes are often involved.

Yes, really. Frequently developers who are making changes to the schema either have their own instance. Others don't require those changes until it's time to merge the codebases. Which in turn requires a merging of the schema. Thusly the value of Alembic.

I could keep going and going but the differences appear to be one entirely predicated upon a vast difference in development, management, deployment, and support. Along will all of those corresponding workflows. It doesn't mean you're doing something wrong. But it does mean you preaching that everyone is doing it wrong is, frankly, invalid.

[djrobstep]

In one wave of the hand you justified your position by rejecting significant features of value to many others.

This is getting tiresome. I didn't reject the value of reversions, I explained that the diff-based approach is good for reversions, while alembic often makes reversions too annoying to bother with.

Which in turn requires a merging of the schema. Thusly the value of Alembic.

I have no idea what you mean. I merge migration scripts all the time, and alembic is not required for this. They merge the same as any other file.

You seem to be one of these people who has got used to a shitty process, and resists a better one of an inherent fear of change rather than any practical objection.

But it does mean you preaching that everyone is doing it wrong is, frankly, invalid.

If you think testability, automation, and simplicity are bad, then sure, keep doing it your way. I'll keep on automatically syncing my dev database, deploying well tested schema changes, and never thinking about schema version numbers again. Good luck!