Look for test name to task id mapping in manifest #108
Conversation
This is an initial stab at exercism#19. It looks for a name to task id mapping in the projects manifest file `metadata.json`. For instance for `leap` the root object should be amended with an object like this: ``` "tests": { "2015 - year not divisible by 4 in common year": { "task_id": 1 }, "1970 - year divisible by 2, not divisible by 4 in common year": { "task_id": 1 }, "1996 - year divisible by 4, not divisible by 100 in leap year": { "task_id": 1 }, "1960 - year divisible by 4 and 5 is still a leap year": { "task_id": 1 }, "2100 - year divisible by 100, not divisible by 400 in common year": { "task_id": 1 }, "1900 - year divisible by 100 but not by 3 is still not a leap year": { "task_id": 1 }, "2000 - year divisible by 400 in leap year": { "task_id": 1 }, "2400 - year divisible by 400 but not by 125 is still a leap year": { "task_id": 1 }, "1800 - year divisible by 200, not divisible by 400 in common year": { "task_id": 1 } } ``` Or whatever the task id is supposed to be. This wasn't entirely clear to me. I've added a module `Manifest.hs` that will look for `metadata.json`. The mechanism used for locating the file simply assumes that the `cwd` is where `.exercism` is located. This might not be the most robust way to do it, but it *is* what the test runner seems to do. So I don't see any immediate benefit to improving this. If `metadata.json` is not located or fails to parse the task IDs are simply set to `null` in the generated report. Here is an example of how the output report changes with this patch for the `leap` task if you were to add an appropriate section in `metadata.json`: ```diff { "message": null, "status": "fail", "tests": [ { "message": null, "name": "2015 - year not divisible by 4 in common year", - "status": "pass" + "status": "pass", + "task_id": null }, { "message": null, "name": "1970 - year divisible by 2, not divisible by 4 in common year", - "status": "pass" + "status": "pass", + "task_id": null }, ``` I've updated the tests. I had one issue with the tests where the GHC/Stack output seems to have changed wording subtly according to: ```diff -Stack encountered the following errors: +Stack encountered the error: ``` I had to add this change to get the tests to work with my local setup, though I appreciate we might need to not include it in the patch or do something else to accommodate the discrepancy.
|
Hello. Thanks for opening a PR on Exercism 🙂 We ask that all changes to Exercism are discussed on our Community Forum before being opened on GitHub. To enforce this, we automatically close all PRs that are submitted. That doesn't mean your PR is rejected but that we want the initial discussion about it to happen on our forum where a wide range of key contributors across the Exercism ecosystem can weigh in. You can use this link to copy this into a new topic on the forum. If we decide the PR is appropriate, we'll reopen it and continue with it, so please don't delete your local branch. If you're interested in learning more about this auto-responder, please read this blog post. Note: If this PR has been pre-approved, please link back to this PR on the forum thread and a maintainer or staff member will reopen it. |
| (|>) :: a -> b -> (a, b) | ||
| (|>) = (,) | ||
| infixl 4 |> |
There was a problem hiding this comment.
I'm not a big Haskeller, but I've never seen this being used in Haskell code (I know the operator from F#, Elm and Elixir). @MatthijsBlom, your thoughts?
There was a problem hiding this comment.
Hoogle: |>. As expected, I spot a few flip ($) synonyms and a lot of cons-likes, but no (,) synonyms. I have never previously seen this use of |> (and such) in Haskell.
This definition reminds me of Julia's =>.
There was a problem hiding this comment.
The right place for this type of data would be in the .meta/config.json file's custom key, the reason being that the metadata.json is only there when one downloads an exercise via the CLI, not in the tooling.
Note: I did forget to document this custom field, but I've just added documentation: https://exercism.org/docs/building/tracks/concept-exercises
There was a problem hiding this comment.
I would also suggest to not modify the existing test case, but instead add a new test case that focuses on the task ids. It might make sense to base this on of the wip concept exercises, like https://github.com/exercism/haskell/tree/main/exercises/concept/pacman-rules, as this example is a practice exercise (leap) and we don't use task IDs for those.
pre-compiled/package.yaml
Outdated
There was a problem hiding this comment.
I'm not sure which added dependency causes this, but the container size balloons from 2.58GB (old, and already very hefty) to 5.15GB (new).
This is an initial stab at #19. It looks for a name to task id mapping in the projects manifest file
metadata.json. For instance forleapthe root object should be amended with an object like this:Or whatever the task id is supposed to be. This wasn't entirely clear to me.
I've added a module
Manifest.hsthat will look formetadata.json. The mechanism used for locating the file simply assumes that thecwdis where.exercismis located. This might not be the most robust way to do it, but it is what the test runner seems to do. So I don't see any immediate benefit to improving this. Ifmetadata.jsonis not located or fails to parse the task IDs are simply set tonullin the generated report.Here is an example of how the output report changes with this patch for the
leaptask if you were to add an appropriate section inmetadata.json:{ "message": null, "status": "fail", "tests": [ { "message": null, "name": "2015 - year not divisible by 4 in common year", - "status": "pass" + "status": "pass", + "task_id": null }, { "message": null, "name": "1970 - year divisible by 2, not divisible by 4 in common year", - "status": "pass" + "status": "pass", + "task_id": null }, ...I've updated the tests. I had one issue with the tests where the GHC/Stack output seems to have changed wording subtly according to:
I had to add this change to get the tests to work with my local setup, though I appreciate we might need to not include it in the patch or do something else to accommodate the discrepancy.