Add API endpoint to get all tracks that implement an exercise?

Exercism
1

Hey there,

I noticed that the website now has overview pages for individual exercises, showing in which track / language we could solve them in. Really cool! :)

Could we also get this as an API endpoint so this information can be used for tooling? Sometimes I would like to tell my editor plugin to start an exercise by first selecting an exercise and then choosing a track instead of starting with a track and then selecting an exercise.

Looks like this is what I’m after?

Greetings, fap

2 Likes
2

Seconded. I do something similar with the 48in24 implementation status dashboard by choosing an exercise first and then seeing what tracks need it.

3

I tend to work in the other axis, pick a land and finish it. It takes all sorts.

1 Like
4

My approach:

Download tracks

for track in `cat track-list.txt`
do
  git clone https://github.com/exercism/$track.git
done

Sync

for track in `cat track-list.txt`
do
  cd $track
  git pull &
  cd ..
done

Which tracks have implemented an exercise?

ls */exercises/practice/$slug/.meta/config.json
5

I’m aware that I can get the info already with the current, but the solution used by @keiraville is not very useful for an editor plugin.

My approach would be to query all tracks via https://exercism.org/api/v2/tracks/$TRACK/exercises, but then I’d have to cache those results somehow as to not hammer the API and to have a quick response time for the plugin.

If it turns this feature is not wort the effort to implement and support it then I’m fine with using the approach I mentioned above, but I’d assume if we make it easier to get from exercise to course then more people will build and use that way of exploring Exercism.

6

Another approach: don’t query Exercism, query GitHub. Fetch and parse the config.json for the tracks. Wouldn’t be any quicker though.

7

So something like /exercises/two-fer/tracks?

1 Like
8

What if it was a single request: GET /exercises returning something like

{
  "exercises": [
    {
      "slug": "two-fer",
      "name": "Two Fer",
      "tracks": ["a", "b", "c", ...]
      ... other attributes of an exercise?
    },
    ...
  ]
}

Is that too much overhead?

9

Could there be track level attributes (eg I think an exercise can be a concept on one track and a practice on another)?

10

As long as a track doesn’t have it already implemented as a practice exercise. That was the problem on the Julia track recently where they wanted to redo leap as a concept exercise instead of a practice exercise. Even if it’s deprecated, you can’t remove the earlier exercise and you can’t have the same slug twice in a track.

So hypothetically yeah, a practice exercise could be a concept exercise elsewhere. I’m not aware of a scenario like that though. I think it’d still be worthwhile to track.

11

I’ve kind of had my eye on lens-person for the jq track. Not as lenses but working with nested data. It’s still a vague plan.