You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
If I am a maintainer of Exercism and I want to review a proposed canonical-data addition or change. I would benefit from examining the tracks that currently have the exercise to get a sense of the scope and see how the changes might affect the tracks.
If I am a curious student and I want to see how a particular task is done in a wide variety of languages.
If I am a potential contributor to Exercism and I want to add an exercise to a track. If I need inspiration from any other similar tracks, I would want to know what are the similar tracks that also have this exercise. This is echoed in Find tracks that implement a particular exercise? problem-specifications#160 where I quote "I find it useful to look at existing implementations of an exercise when adding a problem to a track. This is particularly useful for exercises without a .json file of tests and/or exercises where the description isn't particularly clear as to the author's intent."
You may consider this a subtask of #4118 if you like. Even though the two serve slightly different needs, a solution for this goal may be very useful in a solution for #4118.
If I may, I'd like to use this issue to ask if anyone has any alternatives that I can make use of to get close to answering this question. Some ideas:
Clone all track repos, then simply use the usual filesystem tools to check for the presence of tracks/#{track_id}/exercises/#{exercise_slug} for each track_id. However it seems unfortunate to have to clone a bunch of repos that I will not be contributing to.
Use a tool like curl to ask whether https://github.com/exercism/#{track_id}/tree/master/exercises/#{exercise_slug} exists for each track_id. You get a 404 if the exercise doesn't exist, 200 if it does. I don't want to draw the wrath of GitHub for making requests too fast though.
As above, but using the API, so now https://api.github.com/repos/exercism/#{track_id}/contents/exercises/#{exercise_slug} for each track_id. As before, a 404 if the exercise doesn't exist. I also want to be mindful of any request limits here.
Install https://rubygems.org/gems/trackler/ and use the usual filesystem tools to check for the presence of tracks/#{track_id}/exercises/#{exercise_slug} for each track_id. Doesn't require cloning any repos, but requires the gem to be updated, which it hasn't since July (and why would it continue to get updated, when there is no reason to do it anymore?), therefore the information is out of date since July.
The text was updated successfully, but these errors were encountered:
I'd like to get rid of trackler, as it's getting more and more outdated.
I wonder if this could be built into Configlet, as that tool already does a lot of track-related checking of things.
We could do a couple of things:
pass a flag that says where tracks live on the file system, and if the track is available, check if the file exists. This would need to also check if the repo is on master and master is up to date, and then error or message back if it isn't (don't want to accidentally overwrite anything by switching to master or resetting).
if the track isn't available locally, query the GitHub API to do the actual checking, rather than cloning all the repositories. GitHub best practices say that we should only make 1 request per second if making several, so we could use sleeps for that. We might also be able to use the GraphQL API (not sure if the correct connections exist to get this data directly).
This would mean that it would take about 60 seconds to run the command (worst case). I think having the command clone everything would take longer.
That said, I've also thought about having a command on configlet to clone all the available language tracks, so the documentation could explain that if you intend to run the command often, we recommend that you run the clone everything command first.
Obviously this doesn't forbid future contributors from adding any such functionality in configlet or as an API endpoint on the Exercism v2 website, I just don't want to clog the issue queue with things that I don't need. If someone wants the API endpoint or the configlet functionality I'll let that wanting person create the issue in the appropriate repository.
(Future readers you should not expect that I will provide support for these scripts nor run them for you on your demand, but you are free to run them yourself)
A few motivations why I might want to do this:
This was previously served by e.g. https://x.exercism.io/problems/hello-world backed by https://github.com/exercism/x-api/blob/master/api/v1/views/problem.pg . However, as of the time of writing this issue, https://x.exercism.io/problems/hello-world gives "Please bear with us while we migrate."
You may consider this a subtask of #4118 if you like. Even though the two serve slightly different needs, a solution for this goal may be very useful in a solution for #4118.
If I may, I'd like to use this issue to ask if anyone has any alternatives that I can make use of to get close to answering this question. Some ideas:
tracks/#{track_id}/exercises/#{exercise_slug}
for each track_id. However it seems unfortunate to have to clone a bunch of repos that I will not be contributing to.https://github.com/exercism/#{track_id}/tree/master/exercises/#{exercise_slug}
exists for each track_id. You get a 404 if the exercise doesn't exist, 200 if it does. I don't want to draw the wrath of GitHub for making requests too fast though.https://api.github.com/repos/exercism/#{track_id}/contents/exercises/#{exercise_slug}
for each track_id. As before, a 404 if the exercise doesn't exist. I also want to be mindful of any request limits here.tracks/#{track_id}/exercises/#{exercise_slug}
for each track_id. Doesn't require cloning any repos, but requires the gem to be updated, which it hasn't since July (and why would it continue to get updated, when there is no reason to do it anymore?), therefore the information is out of date since July.The text was updated successfully, but these errors were encountered: