Conversation
The use case for this is extremely rare, to the point where I think it's more benefitial to keep the repository simple by deleting it.
This is super complicated and unmaintainable.
All of these tests are there to prevent people from making mistakes, when the better approach is to automate that work.
Should come in handy as reference, for tests and generation. Also fix a couple inconsistencies in the config.
This is completely undocumented. I guess it's sorting some stuff in the config. Why? I don't know.
This is not the place to teach Windows users how to run Bash scripts.
makes the repo structure less confusing
The scope of these scripts is too big for Bash. They will be rewritten in Rust, with functionality to synchronize with problem-specs.
Both rustfmt and clippy are installed by default these days. I definitely think these tools should be recommended to students, but the installation page is not the best place for that.
```sh git rev-parse --show-toplevel ``` will always work, whereas relative paths may break when a script is moved to a different location in the repository.
One could simply run `configlet sync` anc read from `~/.cache/exercism/configlet/problem-specifications` instead.
In terms of code style, we should just go with the default for any specific language. Rust has rustfmt. Shell scripts should be kept to a minimum such that it doesn't matter.
Some become unimportant when Rust is recommended for non-trivial stuff. Some are now tested, so they don't need to be mentioned explicitly.
This was referenced Sep 11, 2023
I'm not sure why this is the current convention in this repo. Rust files are always snake_case. I'll leave it for now, but might refactor at some point if I can't find the reason.
This was referenced Sep 11, 2023
Some test descriptions have commas and other shenanigans in them. `slugify` solves all those problems with one filter.
This was referenced Sep 12, 2023
ErikSchierboom
approved these changes
Sep 13, 2023
| "prerequisites": [], | ||
| "difficulty": 1 | ||
| "difficulty": 1, | ||
| "topics": [] |
Member
There was a problem hiding this comment.
Why is the topics key added? It is only really there for inspiration for the practices/prerequisites fields, but it serves no purpose from Exercism's viewpoint.
Contributor
Author
There was a problem hiding this comment.
I opened a separate issue for me to consider what to do with this field / how to document it properly. In this PR, they are only added for simple and consistent de-/serialization.
I may or may not clean up empty topic fields when I decide what to do on the separate issue.
This was referenced Sep 13, 2023
This was referenced Sep 14, 2023
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
4 participants
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
This adds a test generator written in Rust. The main goal is to be able to quickly synchronize with problem-specifications. In the process, I rewrote a bunch of Bash scripts in Rust to clean up the tooling.
I changed a couple of things in the track config.json, including on deprecated exercises. Mostly for more consistent de-/serialization. Maybe that's a big no-no?
This is the first step - to have a generator in the repo. The next steps will be to apply it one-by-one to all exercises present in the problem-specifications repository. That will probably lead to iterative changes to the generator as well. Once that's done, I will add CI tests to make sure all exercises are in sync with the version of problem-specifications pinned here as a submodule. Updating will then be a matter of pulling the submodule and pleasing CI tests.
The following is intended as guidance for reviews as well as the commit message of the squash commit if this gets merged.
Add test generator
cleanup dev tooling
bin/check_exercises_for_authors.shcount_ignores.shverify_exercise_difficulty.shlint_tool_file_names.shlint_trailing_spaces.shcheck_uuids.sh:configlet lintcovers that alreadyensure_lib_src_rs_exists.sh:this is not an issue if exercise stubs are generated
clean_topics_vs_practices.py:applies undocumented standards (max 10 practice exercises per topic)
fetch_canonical_data:we now have the submodule for this
cleanup documentation
CONTRIBUTING.mdandmaintaining.mdREADME.mdtoCONTRIBUTING.mdREAMDE.mdfrom Python trackapply conventions and guidelines in a couple places
where the new Rust tests found deficiencies
replace Bash-based exercise generation with Rust-based one
(deleting the related
util/Rust crates)inspired by the python track using Jinja for this purpose
apply test generation to acronym exercise to validate MVP