Ability to uninstall a plugin

[simonw]

@psychemedia in #67 (comment)

plugins: no option to uninstall plugin? (This raised a related issue for me that is more in scope of datasette-cluster-map. If I have that plugin installed, how can I plot markers explicitly (not clustered?) other than by going in to a high zoom level on the map?

[simonw]

From #41 (comment)

• One edge-case: if the user has uninstalled (Ability to uninstall a plugin #72) one of the default plugins (from Bundle a sensible collection of default plugins #81) I will need to remember that they uninstalled it and NOT re-install it on startup. This means I'll need to persist the list of deliberately uninstalled plugins somewhere. I'll handle this as part of issue Ability to uninstall a plugin #72.

[psychemedia]

Trying to enumerate possible situations:

• installed (and being used)
• not installed (in sense of py package not installed in current environment)
• disabled (py package installed in environment "installed" in datasette, but not enabled eg for a particular database)
• uninstalled (py package exists but is not "installed" in datasette)

[simonw]

Part of #74.

[simonw]

If I'm going to have default plugins and I'm going to let users uninstall them, I need a way of remembering what they uninstalled.

I quite like the idea of doing this as an audit log - so every time a user installs or uninstalls or upgrades a plugin we record that permanently somewhere. This could be really useful for debugging later on.

Obviously this should be a SQLite database somewhere. But what should it be called?

Some options:

• prefs.db or preferences.db
• config.db - could be confused with Datasette's concept of configuration (e.g plugin configuration)
• settings.db - definitely confused with Datasette's --setting mechanism

So preferences.db is probably the best option - but do I risk confusion over preferences v.s. settings v.s. configuration v.s. metadata? And what if there's stuff I end up storing in there that doesn't classify as user preferences?

I could call it _desktop.db since it's the internal database for stuff relating to the Datasette Desktop app.

[simonw]

One very slight catch: I need to be able to consult the _desktop database before the datasette process has started up in order to tell which plugins I should avoid installing.

Might have to do that with a custom datasette desktop_plugins /path/to/_desktop.db command using the new register_commands hook https://docs.datasette.io/en/latest/plugin_hooks.html#register-commands-cli

BUT... even that doesn't help me if the Datasette installation is completely corrupted and I need to do a fresh install.

I guess I could install datasette plus default plugins, but then before finally starting the server I could run datasette desktop_plugins --uninstalled-defaults to see if there are any plugins that I should uninstall again? Bit convoluted but it would work at least.

[simonw]

Dropping this from the next release milestone because the debug menu to reinstall Datasette exists as a workaround for the moment.

[simonw]

Putting it back in the release but I'll disallow uninstall for default plugins right now - and label them as such in the plugin directory faceting interface: