generate: Option to ignore problem-specifications

[ZapAnton]

Is it possible for a generate command to ignore the updates to problem-specification and just regenerate READMEs in the track using only local template in the config folder?

I could not find the option in the --help output nor in the README, so had to open an issue (sorry about that)

[rpottsoh]

I think you can do what you want by having a .meta folder within the exercise/{slug} folder that contains a local copy of the template that generate uses. Look into https://github.com/exercism/docs/blob/master/language-tracks/exercises/anatomy/readmes.md

[ZapAnton]

Sorry, @rpottsoh , but this is not what I was looking for.

What I needed was to add a track-wide hint to config/exercise_readme.go.tmpl, run bin/configlet generate . and ensure, that no changes from problem-specification are applied to the READMEs, but only from config/exercise_readme.go.tmpl.

The README you linked talks about adding a .meta folder for every exercise and I feel, that is not the appropriate solution in my case.

[rpottsoh]

I see, I understand. A klunky way would be to not commit changes to the READMEs that are not related to the hint you are adding. Only commit the changes relevant to the addition of the hint.

I can't confirm this but maybe configlet will use description.md from .meta if one is there instead of from problem-specifications. This still involves work, you would have to create description.md files for all the exercises based on each exercises current README (stripping out information that generate inserted) in order to assure the new readme is not affected by the exercise READMEs in problem-specifications. This is all pretty messy.

Configlet would need a patch (or similarly named) feature in order to allow piecemeal changes to individual exercise READMEs for a given language track. I don't believe configlet even reads in READMEs, just creates them.

Thinking outloud...

[ZapAnton]

I have looked through generate source and found this:

track.ProblemSpecificationsPath = filepath.Join(root, track.ProblemSpecificationsDir)

if specPath != "" {
    track.ProblemSpecificationsPath = specPath
}

If I understand it correctly, if no problem-specification is found, then only track folder is searched for changes.

Could it be that a solution for my case is to simply rename/remove problem-specification folder?

[rpottsoh]

I don't think so. generate looks for problem-specifications at the same level as the the track folder. If it can't find such a folder it will err. The -p switch allows you to specify the correct local path to the problem-specifications folder. Locally I call it something else so -p is necessary for me.

[kytrinyx]

@ZapAnton Why do you not want to include any changes from problem-specifications?

[ZapAnton]

@kytrinyx, as I have mentioned in the comment above, there are times, when I would like to make a PR to the language track, that involves editing the track-wide template in the config/exercise_readme.go.tmpl and applying changes to the every existing exercise in the track. In case the problem-specifications repo has been updated, the configlet generate command, aside from regenerating exercise READMEs with my changes, would also include unrelated changes from problem-specification which clutters the PR and makes it harder for maintainers to reason about the changes and to browse the commit history in the future.

For example you may refer to the following PRs:

• https://github.com/exercism/rust/pull/587#issuecomment-409282181
• https://github.com/exercism/bash/pull/207#discussion_r207211478
• https://github.com/exercism/rust/pull/592#pullrequestreview-143391040

Also I suspect, that this PR may also face the same issue: https://github.com/exercism/rust/pull/617

[kytrinyx]

Got it. Thanks, that's helpful.

There's no simple way of doing that using plain Go templates, but if we made a note of what the SHA of the master branch on the problem-specifications repo was at the time of running the generate command, then you could check out problem specifications to the correct SHA, and re-run the generate command without getting any diffs.

I'm not sure where the best place to log the SHA would be.

Maybe just in a plain text file in the .meta/ directory of the exercise?

[ZapAnton]

I am afraid this solution will not help in case when a large amount of exercises is regenerated. First, you need to log SHA for every one of them. Second, different exercises may have been regenerated using different versions of problem-specifications, so you can not checkout on some single version of the repo to make a batch regeneration (you could checkout the repo for each exercise individually but that sounds ... suboptimal)

[kytrinyx]

First, you need to log SHA for every one of them.

The sha should be logged automatically by Configlet when generating. This shouldn't be handled manually.

you could checkout the repo for each exercise individually but that sounds ... suboptimal

That seems perfectly reasonable to me.