I noticed that soon after you created yamlscript-test-runner, you rewrote the generic-test-runner to add bin/bootstrap.sh.
I rebased in the changes and ended up with no diff from generic.
I assume that means you’ll no longer need to create a <track>-test-runner repo for people.
Am I getting all this correctly and can I use the bin script to bootstrap my test runner repo?
No, this is just for us to do it easily. Your repo is at GitHub - exercism/yamlscript-test-runner and is what should be used.
If you see my message above, that gives you the minimal changes you need to do 
Gotcha. Yeah I ran the script and it didn’t work (of course).
Trying it did lead to this PR: Check that deps for bin/bootstrap.sh are installed by ingydotnet · Pull Request #148 · exercism/generic-test-runner · GitHub
Greetings. I’ve finally found the time to set aside the next few days to get the YAMLScript Exercism Track moving forward.
First question is Implement hello-world by m-dango · Pull Request #6 · exercism/yamlscript · GitHub
Also is the appropriate place to chat about things?
I’m also working with @m-dango in another place.
3 Likes
You could use this thread to chat about things, and you could also use discord or GitHub. Whatever you prefer.
@ErikSchierboom I was unable to reply to your message here. I emailed @iHiD about it. Not sure what’s going on. Had some issues with this forum yesterday but @iHiD addressed them after I reached out to him.
Editing this since it went through. I wrote this using the [Reply] button next to the [Bookmark] button.
The one that failed I used the “Reply” link in your last message…
@ErikSchierboom I think Create version 1 test runner by m-dango · Pull Request #5 · exercism/yamlscript-test-runner · GitHub is (actually now) ready for review.
Looks good. I’ve approved.
1 Like
One thing I’m trying to figure out is what things can easily be changed after launching a track and which things really shouldn’t.
For instance I’m currently naming my test files exercises/practice/$slug/test/test-1.ys. I’m not completely satisfied with that scheme yet, but I’m also not satisfied with several others I’ve considered. What kind of pain would changing test file names later on cause? Note on test files, they can be named anything and don’t require to be under a directory called test/.
You’d need to change the relative path for the test file in the exercise’s config file under files → test . You probably want to also update the files → test pattern in the track config if you’re using configlet to create additional exercises since it uses those patterns to set up the initial files.
That might affect the example tests for the test runner depending on how test detection happens. It might also affect the CI for verifying example solutions in the main track repo.
How to change it seems straightforward.
What I’m wondering is how users who’ve already downloaded an exercise using the previous naming scheme would be affected.
And that goes for any kind of change, not just test files. What are the kinds of changes that would cause problems for already active users?
The only real problematic changes are those you already mentioned, where the structure of files change. I would suggest to get this “right” before launching.
In Add initial exercises | Exercism's Docs “raindrops” is an intermediate difficulty exercise.
Why do I get difficulty=1 here: tmp.DavCp4Bn0f · GitHub
(I get difficulty=1 for everything I’ve created)
I believe there’s no canonical difficulties for exercises. The difficulty is dependent on the language and cannot be set cross-tracks.
Also, that doc maybe should be updated; I think Raindrops is easy on most tracks.
1 Like
So in the root config.json
practices, prerequisites, difficulty, and topics are placeholders for the track to fill in?
Perhaps difficulty should default to 0 or null.
It seems like slug and uuid are important to leave alone.
It would be really useful to have a complete list of all the parts (not just config.json) of a track that the track maintains, the parts that should never change, and the parts that exercism changes for you (and when/how those changes happen).
Does this already exist?
Correct.
Eh. 1 is a valid value and can be used to launch the track. Changing them isn’t crucial. And they can be hard to set so you may want to adjust them over time as people try to solve the exercise.
The slug should be exactly what is found in the canonical data. The UUID is randomly generated. Any valid UUID that isn’t used elsewhere is fine.
This thing? config.json | Exercism's Docs
Thanks for your responses
As a new track creator I’m given 2 repos, but it’s not yet clear to me which files (or specific parts of data files) I’m free to change and which ones will be updated by bots or by sync commands I’m supposed to run later on. I just make educated guesses but leaves me wondering.
If there was documentation explaining how the entire exercism system works, that would be excellent. Is there?
BTW, I’m not lost here, just want a better understanding.
I’ve already written tooling that can generate over 80 exercises from the problem-specifications repo (minus the example solution )
It’s a much better idea to not optimise early. Make it work, then Erik and the rest of us can help you slim it down. Python on alpine for example is a bad idea because it’s extremely slow (for Python specifcially). JS/TS run on node:20-bookworm-slim.
There are pretty solid track docs in the building section. That area of the docs might be clicking around.
1 Like
To answer your unanswered questions:
- No such a list of what is immutable or what is changed by Exercism/supplied doesn’t exist canonically
- Correct, UUID must be unique-globally and is important to leave once it exists.
- Correct, slug must be unique-per-track and is important to leave once it exists.
- Most of the other things you can indeed find in the docs provided by @IsaacG but feel free to ask for clarification here.
1 Like