I know about --sql but what I mean is generating versioned sql scripts that Alembic knows how to linearize and run. I found that unless Alembic's Python migration script generation gets really good fast, I really need to run plain SQL migration scripts. Case in point, triggers, indices, unique constraints, enum types for PostgreSQL, custom column data types, foreign key constraints cascades, GeoAlchemy DDLs and functions… etc.
I really would like to use Alembic's way of versioning scripts, it's a clear advantage over sqlalchemy-migrate, but I would also like to be able to dump the data from the database, paste the inserts to a generated, versioned SQL script instead of converting the data back to possibly 100s of Alembic inserts.
yeah, I am now familiar with migrate's .sql file thing and IMO it's not very useful. Such files would not be portable to Alembic anyway as Alembic requires the file itself to include metadata about the version and its dependencies, which means we'd need to invent some new markup system (like YAML inside of a sql comment or something) and it might as well remain a Python file with a SQL string inside of it.
Well, FWIW, my idea was the usual python file with something like op.execute_file("whatever.sql"), where execute_file does sqlparse.split() (or equivalent) since op.execute() doesn't like large payloads. I don't really care about the part of using sql files as if they were the whole script.