Auto-updates + Config Migration

[jaidetree]

An interesting problem, @agzam mentioned, that rears its head again when implementing fixes like #121, is we don't have a great way of communicating new potential settings and their defaults to existing users.

The current system favors stability and our goal as maintainers is to only introduce additional config, but it also means existing users may not know about these new options like being able to set a ratio for how to center windows on the screen.

I'm thinking we could create a migrate.fnl script that users can run after updates that will communicate new default settings.

Basically it be a list of objects that check for the presence of a new setting, inform the user what it's used for, and gives them the option of adding it to their config or not.

[
  {:title "Default window-center-frame ratio"
   :description "Customize the ratio used to center windows on screen. Defaults to 80:50 which is 80% screen width and 50% screen height. Also adds an advisable position-window-center function in windows.fnl for customization."
   :check-for (fn [config] config.modules.windows.center-ratio)
   :migrate (fn [config] (assoc-in config [:modules :windows :center-ratio] "80x50"
]

Usage example:

./migrate.fnl

------------------------------------------------------------------------------
Default window-center-frame ratio
Customize the ratio used to center windows on screen. Defaults to 80:50 which is 80% screen width and 50% screen height. Also adds an advisable position-window-center function in windows.fnl for customization

Would you like to update your config with this new default setting?

> (Y/n) Y

  [ Config Updated ]

... repeats ...

The other feature @agzam expressed interest in was some kind of auto-update functionality. He mentioned leveraging homebrew for this. I'm not quite sure I understand how that would work but I'd like to hear more!

Alternatively we know spacehammer users are likely to have at least git and hammerspoon installed. Maybe we could have it check either on startup or once every week for spacehammer releases (or latest commit-sha) and if it has changed, display a UI for users to automatically run the git commands git pull https://github.com/agzam/spacehammer.git master --rebase and perhaps iterate through the migrations list from migrate.fnl and walk the user through updates.

A potential enhancement to that would be remembering what users select for each migration so if they skip it, we don't prompt them again. But that's more of an edge-case not really a release blocker.

[Grazfather]

I have been thinking about this a bit.

Forcing a new schema sucks, but it might be (eventually) worthwhile. If the config were to codify a schema version in it we could make converting over less painful. So our example config.fnl, when we have a new schema, introduce a :schema key. Take the missing key as schema v1 or whatever we think we're on now.

core could detect old schemas and warn users that they are using a deprecated schema, and if someone were brave they could write something like schema-v1->schema-v2 functions that fix it where we can. Maybe a script to invoke it on the command line to show the changes so that a user could try to incorporate the transformation into their config.

"Compatible" schema changes could just be new features added as new keys that don't break a config, but the user loses out on the new feature. We can still warn in these cases and offer the transformation. Incompatible changes would be things like removing or moving keys. We could use something like semver to differentiate the two.