Initial features: schema for hierarchical config, config directory, variant directories, template directories

[Vaughn Kottler]

Choose a default location on disk where this package looks for the "data repository" location (.config/rcmpy/something?)

add a command-line tool to symbolically link an arbitrary "data repository" directory to that default location (or, should we update our own internal state database? maybe the latter)

keep state and statistics for each file? operations:

• use <directory> use this new directory as the root of the data repository
• apply [--diff] compile templates then follow instructions from some configuration data for where to try to put files

[Vaughn Kottler]

project-81/workspace#2

maybe use this convention for templates:

templates/
  common/
  <variant-1>/
  <variant-2>/

this way you can do things like keep track of per-user configuration files and promote/demote their preferences to and from common.

Allow "variant" templates to take precedence over common ones.

Figure out how to handle variant being default or not set (probably should start as None)

[Vaughn Kottler]

Determine location to save state persistent across runs (settable via CLI). Store schema for this in package data

[Vaughn Kottler]

Added a bit of documentation, now we need to just continue fleshing out the data repository config schema and the directory layout etc.

[Vaughn Kottler]

still chipping away at this

[Vaughn Kottler]

#9 We can do pretty much everything except render templates based on config data.

need to implement loading + detecting changes for that next, also need to make sure that "is config data changed" is considered when re-rendering templates

[Vaughn Kottler]

need to figure out how we want to structure configs (and: if we want datazen-style "variables" too or not)

[Vaughn Kottler]

configs/
  common/
  <variant-1>/
  <variant-2>/

variables/
  common/
  <variant-1>/
  <variant-2>/

same thing for those two things?

[Vaughn Kottler]

I think to simplify change detection, we should just store something like "last compiled config" and then compare that wholesale to the current config

also: we need a way to force a template update if variant has changed. seems like detecting variant change would be ideal here. we probably need to leave behind some data on the last apply invocation

[Vaughn Kottler]

We're using this now