Seed 2019-06-27
Here's the current thing that has me tripped up regarding Seed:
A seed repo is essentially a template that gets filled in to create a basic 0.1.0 version of a new repo. In getting filled in, it has to have some kind of environment defined to map variable names to values. What ultimately gets filled in should usually be a string, but more elaborate data structures might sometimes be called for, such as an array of strings to represent a list of authors. The seed repo can use any set of variable names that the seed creator desires. There are various possible features that we might prioritize in order to choose a workflow for passing in variable values:
- Constraining choices of value or specifying a default
- Presenting the variables to the user in some defined order
- Allowing the user to specify structured data
Here's what I'm leaning towards for now, as an initial implementation at least:
The seed.toml file contains a "substitutions" table, where the keys are variable names. Each key is documented in a comment that precedes it. Keys may have a value already specified, or may be left blank. Documentation should mention any restrictions on allowed values. When the user performs an initial fork, the seed program should open the seed.toml file in an editor; after the user saves, the program should append a table containing just the relevant patches.
(The invariant of the "relevant" patches is that those patches should be the parents in the seed repo of the patch in the current repo.)
Updating the patches goes as follows:
Update the referenced patches, ideally to a tag for simplicity, and commit only the changes to seed.toml. Submit that patch for updating. In a new clone, that patch gets its own branch, and then the relevant patches are pulled from the seed. The program attempts to apply the merged seed.toml to the seed repo; if it fails, it drops the user into an editor and prompts them to fix the variables. Once the new version creates successfully, it gets tested green, then tested red if that fails. I'm still not fully comfortable with this flow; there are possible avenues of failure that I'm not sure what the right way to recover from them is. That said, I'd like to start prototyping these ideas when I have time, which is not right now, because I spent all day working this out in the first place, and doing other stuff.
Good night.