Please refer to the README file for installation instructions and some basic info.
Currently, it supports only one command (which was the main reason I built the tool in the first place): backup. This allows you to back up the solutions you’ve submitted to the Exercism platform.
By default, this command will download all your solutions (to all exercises, in all language tracks):
auxiliaire backup <destination_directory>
It supports filtering by track (--track rust), exercise (--exercise bob) and even status (--status published).
In particular, --iterations can be used to back up iterations as well!
Running auxiliaire backup --help will provide more information.
I still consider the tool to be pre-release because I haven’t really written proper tests for all cases, but it’s been tested by its original intended audience (e.g. me) successfully so far. Feel free to leave feedback via the GitHub project.
The tool is written in Rust; contributions are welcome! See CONTRIBUTING.md for details.
I forgot to mention that in order to work, the tool needs an API token. However, by default, if you have the Exercism CLI installed locally, it will reuse the API token specified for that tool. If you don’t have the Exercism CLI, you’ll have to pass the API token via --token.
So I’m reviving this thread because during my hiatus from Exercism this year, the Exercism API has had very aggressive throttling added (for good reasons). Unfortunately, this does seem to make a tool like auxiliaire very difficult to implement. I tried to add retry support (with exponential backoff) but the default setting (five retries) doesn’t seem to fix the issue.
@iHiD Sorry to ping you directly, but given that the tool’s main goal was to backup a user’s solutions and given that this has now been added as a feature to Exercism directly (which can probably be much more efficient in terms of resource use), I reckon it might be time to retire the tool. Any opinion? I’d like to avoid straining Exercism’s resources any further unless required.
If you get rate limited (HTTP 429), the response should tell you how long you need to wait until the next request. If you sleep that duration, the next request ought to work. See here for example.
With the rate limiting in place, I’m pretty sure the load by such a tool is very minimal. I discussed the Discord #mentor-requests bot with Jeremy, and that tool makes a whole lot of requests. The load any one IP can add is quite small thanks to the rate limiting.
Interesting, I didn’t know about this standard header. It looks like the Rust library I tried to support retries doesn’t support it natively, but I’ll look into it. Thanks!
thread because during my hiatus from Exercism this year, the Exercism API has had very aggressive throttling added (for good reasons). Unfortunately, this does seem to make a tool like