Rotating Tournesol Time

I think I have just discovered that Alembic (the SQLAlchemy migration tool) has no facility for writing out offline SQL files for merge revisions, and I'm not sure why.

Looking at the code for my installed 1.8.1 version, the underlying “iterate up to the target from multiple heads” functionality seems like it should work just as well as it does in online mode, but the types on the way to the public interface and CLI just have no way of stuffing multiple revision IDs into the from-side of the range.

Specifically, MigrationContext.run_migrations calls get_current_heads for its starting revision set, which supports hydra revision sets in its return type and will happily return them when called on an online database in a hydra migration state. But when get_current_heads is called in offline mode, it reads the _start_from_rev attribute, which is declared elsewhere as Optional[str]—and the promising-looking util.to_list call in there doesn't have any string-splitting in it, sadly. In theory, if we can get a tuple into _start_from_rev we should be golden… that comes from opts, which is ultimately passed through via EnvironmentContext.configure…

The argument to that is typed as Optional[str] as well, but it looks like maybe if I could smuggle it in through the configuration context and unpack it in a custom env.py it might sort of maybe work—but out-of-tree jiggery-pokery in violation of the declared type (much less reaching in and setting the attribute directly or something) seems risky.

So assuming I don't want to do that, I need to do at least one of giving up on the offline-primary approach I wanted and just taking a runtime dep on Alembic (presumed workable, just irritating for Reasons), enforcing linear history (also probably workable, differently irritating), or poking the Alembic discussion board until something interesting pops out.

For that third option, I'll need to find the fob for my GitHub account, which I'm pretty sure is somewhere under these piles of stuff on my desk…