create: New command to set up a new exercise/approach/etc

[kytrinyx]

From the perspective of someone using configlet to help bootstrap a track, it would be helpful to have a command that takes the --exercise argument and assumes that you have not done anything yet to start working on that exercise.

Maybe configlet init --exercise two-fer or configlet bootstrap --type practice --exercise two-fer or something like that.

It would do something like:

• write an entry to the track-level config.json with all the required keys.
  • fill in the slug based on the value passed to the --exercise
  • fill in the name based on the metadata.toml (if it's a practice exercise and exists in problem-specifications) or by making a guess based on the slug (e.g. sugar-fish would transform to Sugar Fish).
  • fill in the uuid by generating a new one
• sync docs, metadata, and filenames (without asking for permission)
• add empty files for all the files specified in the config.json
• (maybe?) syncing tests interactively, but with the option of saying [a] for [a]ll instead of just [y]/[n]/[s] individually?

This is a follow-up from exercism/problem-specifications#2122 (comment)

[ErikSchierboom]

Or maybe configlet new? I would love this feature.

[ee7]

I don't have an opinion on the name yet, but we might also consider configlet create.

[kytrinyx]

I don't feel strongly about any of the names; I think they all describe what we want well, and with the --exercise flag we wouldn't be confused about what type of thing it's acting on.

I have a slight preference for using a verb-like name, since sync and lint are both verbs. And fmt sort of is a verb, given that it stands for format.

[ErikSchierboom]

@kytrinyx So create over new?

[kytrinyx]

@ErikSchierboom Yeah, I would prefer create (or bootstrap or init). I think create makes the most sense, having slept on it some more.

[ErikSchierboom]

Okay. Let's go with create then.

[ee7]

Possible design:

configlet create \
    [--concept-exercise | --practice-exercise | --concept | --approach | --article] \
    [-y,--yes] \
    [-o,--offline] \
    foo

where, trying to be similar to configlet sync -u:

• a plain configlet create interactively asks the user what they want to create
• configlet create --practice-exercise without -y asks the user to confirm
• configlet create --practice-exercise -y is non-interactive
• omitting --offline means that it may update the prob-specs cache if appropriate

Thoughts?

[kytrinyx]

This looks excellent. I like the parallel structure to sync.

For a practice exercise, would we then call configlet sync manually afterward, or would this do it for you?

[ee7]

For a practice exercise, would we then call configlet sync manually afterward, or would this do it for you?

We'd have to think a bit, but maybe something like:

• If the user says they want to create a practice exercise
• but does not pass -o, -offline
• then configlet updates the prob-specs cache before writing files, because create should probably create an exercise .meta/config.json, and for a practice exercise that file contains metadata from prob-specs. Updating the cache means we create it with up-to-date metadata.

It seems like it might be nice to automatically add docs and tests too, and for create to run a test generator. But I think create would then have to accept some subset of the configlet sync options (e.g. --tests include), so that test syncing can be configured. So maybe combining them does more harm than good, and it's better to try to leave create and sync separate. What were you leaning towards?

[kytrinyx]

I'm also leaning towards leaving create and sync separate.

[ee7]

Should configlet ever learn how to run a track's test generator? Otherwise, the process is like this:

• configlet create
• configlet sync --update
• ./bin/generate-tests

[kytrinyx]

I'm leaning towards "no" at the moment. I've been doing some work on language-agnostic generators lately, and my sense is that we'd be better served by incrementally tweaking configlet to make generator stuff work more smoothly.

I might change my mind down the line, but at the moment generators are a bit murky and messy, so I don't want to jump the gun and have configlet do things that we're going to regret later.

[ee7]

I was leaning that way too. I think otherwise we'd want a spec for generators, possibly with some configuration in the track config.json file.

[ErikSchierboom]

I'd also prefer configlet to be generator agnostic.