All of this is boilerplate, I've separated it into its own diff so as not to complicate review of all the manual stuff. We could maybe condense this by having our own library functions, like dagster.utils.sql.run_migrations_offline and dagster.utils.sql.run_migrations_online.
This is fine. More high level, can I get context as to why are we doing this? This is weird that we are saying, you have to use alembic if you use the dagster postgres library. Also why is run storage coupled so tightly to this lib? Is this lib purely internal? (Sorry I am catching up here)
Context is, we need some way to version and migrate the schemas for our storages. The dagster-postgres library contains postgres-backed storages. We are trying to use a single schema definition for all of our SQL-backed storages, so that we can have unified migration tooling. (Obviously if you write your own storage class, you don't need to worry about backwards compatibility if you don't need to worry about it.)
Got it. Essentially, clients who want to use our postgres backed solution, get this for free and need to use alembic. If they disagree they can implement their own thing (with relative ease since it's all configurable in DAGSTER_HOME. Cool!