Make disabling plugins less tricky
|Reported by:||Christopher Allan Webber||Owned by:|
Now that we're using Alembic's branching model to enable long-running plugin migration branches, disabling plugins has gotten... complicated. From the current git master docs:
Deactivating plugins ==================== You should be aware that once you enable a plugin, deactivating it might be a bit tricky, for migrations reasons. In the future we may produce better tooling to accomodate this. In short, you will need to do a bit of database surgery by: - Removing all tables and indexes installed by the plugin - Removing the plugin's migration head id from the `alembic_version` table. (You might be able to determine which to remove via examining the output of `./bin/gmg alembic heads`) Note that this is a VERY TRICKY process, and you should be sure to make a backup first. You've been warned!
Well, obviously this isn't great. And the reason this isn't great is if you disable a plugin, the revisions for that plugin can't be found (because they aren't made available to alembic's migration path), and thus alembic is like "wtf is going on?"
So anyway, the docs suggest a method of "database surgery" to be able to install things, but of course manual surgery is unreliable. We should provide a parameter so that plugins can define their own "uninstall" rule that does this kind of manual surgery *for* the user (deleting tables, etc), and then delete the latest revision for that branch path.