id	summary	reporter	owner	description	type	status	priority	milestone	component	resolution	keywords	cc	parents
5447	Make disabling plugins less tricky	Christopher Allan Webber		"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."	defect	new	major		programming		medium