# Autograder.io Command-Line Interface
A command-line tool for managing assignments on Autograder.io.
We also recommend Amir Kamil's [autograder-tools](https://gitlab.eecs.umich.edu/akamil/autograder-tools/tree/master) as a complimentary collection of applications.
## Announcements
Version `2024.08.0` is out!
All project configuration options (e.g., core settings, files, tests, handgrading) should be supported in this version.
Please open an issue to let us know if you spot something we missed.
## Quickstart
### Install
Replace `<version>` with `YYYY.MM.*` of your deployment's version of Autograder.io.
You can check your deployment's version by viewing the API docs at `yourdeploymentdomain/api/docs`.
For example, if your deployment is on version `2024.08.0`, replace `<version>` with `2024.08.*`.
This will install the most recent version of the CLI compatible with Autograder.io `2024.08.0`.
```
pip install --pre autograder-cli==<version>
```
### Obtain API Token
Visit https://autograder.io/web/__apitoken__ and sign in.
Save the file you are prompted to download as `.agtoken` in your home directory or the directory.
Check that you've authenticated correctly with the following command:
```
ag http get /api/users/current/
```
This command should return your user information.
**IMPORTANT**: If you are using your own deployment of Autograder.io, you will need to specify the base URL of that deployment for every command you run.
Specify the base URL with the --base_url flag, e.g.:
```
ag --base_url https://your.url.com http get /api/users/current/
```
You may want to alias `ag --base_url https://your.url.com` in your shell profile for convenience.
### Configure Autocomplete in VSCode
1. Install the [VSCode YAML plugin](https://marketplace.visualstudio.com/items?itemName=redhat.vscode-yaml) (published by RedHat).
2. Generate the Autograder.io CLI JSON Schema:
```
ag write-schema
```
This will create a file called `autograder_io_cli_schema.json` in the current working directory.
3. Add the following to your VSCode settings.json:
```
"yaml.schemas": {
"/path/to/autograder_io_cli_schema.json": [
"agproject.yml",
"*.agproject.yml",
"agproject.*.yml"
]
}
```
This will cause the YAML plugin to recognize `agproject.yml` and `*.agproject.yml` files as using the Autograder.io CLI schema.
NOTE: The plugin flags an empty `settings` key as an error.
Leaving `settings` blank is allowed and will use the default field values.
Pull requests are welcome that add instructions for setting up autocomplete on other editors.
### Common Usage
#### New Project From Scratch
Use the following command to create a project config file with default values.
Replace `'My Course' Fall 2025` with the name, term, and year of your course.
Replace `'My Project'` with the name of your assignment.
The course you identify by name, semester, and year must already exist before you can save the project.
This only creates the config file locally, it does not save any changes to Autograder.io.
```
ag project init 'My Course' Fall 2025 'My Project'
```
This will create a configuration file `agproject.yml`.
You can choose a different name with the `--config_file` flag.
This CLI attempts to detect your local timezone.
You can change the `timezone` field in the config file if you wish to use a different timezone.
See [Save a Project](Save-a-Project) to save your configured project
#### Download (Load) an Existing Project
This command loads settings for an existing project and writes the settings to a file.
It also downloads instructor files associated with that project.
For example:
```
ag project load 'My Course' Fall 2025 'My Project' myproject.agproject.yml
```
will download the specified project and save its configuration to the file `myproject.agproject.yml`.
Instructor files for that project will be saved in the same directory as the config file.
That is, if you specify `../some/path/myproject.agproject.yml`, the instructor files will be saved to `../some/path/`.
#### Save a Project
To save your configured project to Autograder.io, run the following command from the same directory as the config file:
```
ag project save
```
You can specify a different config file with the `--config_file` flag.
## FAQ and Tips
### Repeating Test Cases
The config format provides a "repeat" mechanism for defining groups of similar test cases in a compact way.
For example:
```
project:
# Project information and settings
# ...
test_suites:
- name: Python Unit Tests
test_cases:
# $test_label is a user-chosen placeholder.
# The leading $ is not required but helps readability.
- name: Test $test_label
cmd: python3 -m unittest -k $test_name
return_code:
expected: zero
feedback:
normal: pass/fail+timeout
final_graded_submission: pass/fail+timeout
# Define substitutions for our placeholders
repeat:
- $test_label: Normal 1
$test_name: normal1
# Specify specific values for this test case.
_override:
return_code:
points: 2
- $test_label: Edge 1
$test_name: edge1
_override:
return_code:
points: 3
```
Saving this configuration will create two test cases with the same feedback and expected return code settings, but with different names, commands, and point values.
### Default Values
Since there is not a perfect one-to-one mapping between CLI project configuration options and API fields, there are some cases where the CLI and API have different default values.
Removing a field from the config file and then saving the project will reset that value to its CLI default.
The `ag project init` command creates a config file with all fields present and set to their CLI defaults.
In contrast, the `ag project load` command creates a config file that only contains non-default values.
### Feedback Presets
The config file supports several presets for test case feedback settings.
You can also define your own feedback presets under the `feedback_presets` key (for single command tests or the commands in multi-command tests) and the `feedback_presets_test_suite_setup` key (for test suite setup commands).
The config file created by `ag project init` contains definitions for several built-in presets.
Do not edit the contents presets.
However, once you are familiar with the CLI's built-in presets, you may remove them from the config file.
The CLI will recognize them even if they are not present in the config file.
### Sandbox Images
The CLI does not yet support building sandbox images.
Please build your images through the Autograder.io website.
In test suite definitions in the config file, you may specify the name of any sandbox image you've built for the course on Autograder.io.
### Deleting Entries
The CLI currently does NOT support deleting entries such as instructor files, expected student files, or test cases.
Removing these entries from the config file and saving the project will NOT delete those entries.
If you need to delete those entires, please do so through the Autograder.io website.
### Renaming Entries
The CLI does not yet support renaming entries.
Changing the name of an entry will cause a new entry to be created.
Please rename entries through the Autograder.io website.
We are currently considering solutions for renaming.
Our goal is to balance ease-of-use, predictability, and complexity of the implementation.
Please let us know if you have suggestions by commenting on [this issue](https://github.com/eecs-autograder/autograder-cli/issues/6).
## Versioning
This package uses calendar versioning following [Python conventions](https://packaging.python.org/en/latest/discussions/versioning/), with version numbers of the form `yyyy.mm.X`, where `X` is for minor versions.
For example: `2024.8.0` corresponds to August 2024.
We also make use of pre-release tags such as `.devX`.
The year and month of the release specify the earliest version of the Autograder.io API this package is compatible with.
However, the minor version number **does not correspond** to Autograder.io's minor version numbers.
Also note that backwards-incompatible changes to the Autograder.io API may make future versions of that API incompatible with earlier versions of the CLI.
### Development & Release Branches: Protocols and Workflow
This section is intended for developers.
#### "develop" branch
Use feature branches for all changes, and make a pull request against the `develop` branch.
The `develop` branch is for changes based on the `develop` branch of the `autograder-server` repo (which is a submodule of this repo found at `tests/local_stack/autograder-server`).
Update the submodule `develop` branch when starting work on a feature that depends on new `autograder-server` commits.
Use the following steps on your feature branch:
```
# Fetch latest submodule commits
git submodule update --remote
# git status should show new commits in the submodule
git status
git add tests/local_stack/autograder-server
git commit -m "Update submodule"
```
#### "release-*" branches
Name release branches as `release-YYYY.MM.x`, replacing YYYY with the full year and MM with the zero padded month (e.g., `release-2024.08.x`).
The month format differs from the Python package versioning (e.g., `2024.8.x`) so that branches are sorted properly.
Do NOT merge or rebase directly between the develop and release branches.
Once a release branch is created, it should only be updated with feature- or bugfix-style branches.
We generally recommend a squash-and-merge for these types of PRs.
After the squashed feature/bugfix branch is merged into a release branch, cherry-pick the squashed commit on top of `develop` and open a pull request to merge the changes into `develop`.
Release branches should keep the corresponding `autograder-server` submodule release branch up to date.
Follow the same protocol as for the `develop` branch.
For the first release of this library (2024.8), there will be a time period of adding features to the release branch until we support all project configuration options.
At time of writing, handgrading options are the main missing piece.
The version of `README.md` (this file) on the `develop` branch is the source of truth.
Update this file on release branches just before publishing a release.
If instructions differ across releases, include both, and label which version the instructions apply to.
#### Publishing a release
To create a github release, tag the latest commit on the release branch.
For example, to create the first non-dev 2024.8 release, we'd run:
```
git checkout release-2024.08.x
git tag 2024.8.0
git push --tags
```
CI will build and test the package, publish to pypi, and create a GitHub release.
## Dev Setup
### Clone the Repository
```
git clone --recursive git@github.com:eecs-autograder/autograder-cli.git
cd autograder-cli
```
If you omitted the `--recursive` flag, initialize the submodule with:
```
git submodule update --init
```
### Install Dependencies
Create and activate a virtual environment:
```
python3.10 -m venv venv
source venv/bin/activate
```
Install package dependencies and install the autograder-cli as a local editable package:
```
pip install pip-tools
./dev_scripts/install_deps.sh
```
Install [dyff](https://github.com/homeport/dyff) for comparing yaml files in test cases:
```
curl --silent --location https://git.io/JYfAY | bash
```
### Build the Local autograder-server Stack
Build and start the stack:
```
./dev_scripts/local_stack.sh build
./dev_scripts/local_stack.sh up -d
```
`./dev_scripts/local_stack.sh` is an alias for a docker-compose command.
Generate the gpg secrets for the autograder-server stack:
```
python -m pip install Django==3.1 python-gnupg
cd tests/local_stack/autograder-server && python3 generate_secrets.py
cd -
```
[Running the tests](Tests) will finish preparing the stack by applying migrations and clearing the database.
### Linters
Run isort, black, pycodestyle, pydocstyle, and pyright to check for style, formatting, and type issues:
```
./dev_scripts/lint.sh
```
Python code should be formatted using isort and black.
### Tests
Build and start the local stack as described above, then run the tests with:
```
./dev_scrips/test.sh
```
This script does a few preparation steps and then invokes pytest.
Extra command line arguments to `test.sh` are passed through to pytest, e.g.:
```
./dev_scripts/test.sh -k test_project_init
```
This project uses pytest as its test runner.
Most of the test cases are currently "roundtrip" tests that save and load a configuration.
To generate a new roundtrip test, run:
```
./dev_scripts/new_roundtrip_test.sh {test name}
```
The test name can include directories (e.g., ag_test_suite/setup_cmd).
This will initialize a roundtrip test in tests/roundtrip/{test name}.test.
Roundtrip tests consist of the following steps:
1. Save the project found in `{test name}/agproject.create.yml`.
2. Load that project and compare the loaded version with `{test name}/agproject.create.expected.yml`.
3. Save the project found in `{test name}/agproject.update.yml`. (this is intended to be the same project that was created in step one, but with some fields changed)
4. Load that project and compare the loaded version with `{test name}/agproject.update.expected.yml`.
When testing deadline formats (e.g., fixed cutoff, relative cutoff), you can specify which format to load deadlines into in the file `{test name}/deadline_cutoff_preference`.
In the `.expected.yml` files, if you haven't set any values in `project.settings`, you will need to set `project.settings` to an empty dictionary.
We haven't made the `new_roundtrip_test.sh` script make this change because it serves as a way to have new test cases fail until they are edited.
### The HTTPClient
The `HTTPClient` class is a starting point for sending custom requests in Python applications.
```
import json
from ag_contrib.http_client import HTTPClient, check_response_status
client = HTTPClient.make_default()
response = client.get('/api/users/current/')
check_response_status(response)
print(json.dumps(response.json(), indent=4))
```
#### HTTP Client Command-Line Interface
This library provides a minimal command-line interface for sending custom HTTP requests to the Autograder.io API.
Run `ag http --help` for more details.
Raw data
{
"_id": null,
"home_page": null,
"name": "autograder-cli",
"maintainer": null,
"docs_url": null,
"requires_python": ">=3.10",
"maintainer_email": null,
"keywords": "autograder, autograder.io",
"author": null,
"author_email": "James Perretta <jameslp@umich.edu>",
"download_url": "https://files.pythonhosted.org/packages/05/5b/d15291b2c4a7e8e94f06c53f4371e16e1b8868fc9b767db16ced1b2e89b4/autograder_cli-2024.8.0rc1.tar.gz",
"platform": null,
"description": "# Autograder.io Command-Line Interface\nA command-line tool for managing assignments on Autograder.io.\n\nWe also recommend Amir Kamil's [autograder-tools](https://gitlab.eecs.umich.edu/akamil/autograder-tools/tree/master) as a complimentary collection of applications.\n\n## Announcements\nVersion `2024.08.0` is out!\nAll project configuration options (e.g., core settings, files, tests, handgrading) should be supported in this version.\nPlease open an issue to let us know if you spot something we missed.\n\n## Quickstart\n### Install\nReplace `<version>` with `YYYY.MM.*` of your deployment's version of Autograder.io.\nYou can check your deployment's version by viewing the API docs at `yourdeploymentdomain/api/docs`.\nFor example, if your deployment is on version `2024.08.0`, replace `<version>` with `2024.08.*`.\nThis will install the most recent version of the CLI compatible with Autograder.io `2024.08.0`.\n```\npip install --pre autograder-cli==<version>\n```\n\n### Obtain API Token\nVisit https://autograder.io/web/__apitoken__ and sign in.\nSave the file you are prompted to download as `.agtoken` in your home directory or the directory.\n\nCheck that you've authenticated correctly with the following command:\n```\nag http get /api/users/current/\n```\nThis command should return your user information.\n\n**IMPORTANT**: If you are using your own deployment of Autograder.io, you will need to specify the base URL of that deployment for every command you run.\nSpecify the base URL with the --base_url flag, e.g.:\n```\nag --base_url https://your.url.com http get /api/users/current/\n```\nYou may want to alias `ag --base_url https://your.url.com` in your shell profile for convenience.\n\n### Configure Autocomplete in VSCode\n1. Install the [VSCode YAML plugin](https://marketplace.visualstudio.com/items?itemName=redhat.vscode-yaml) (published by RedHat).\n2. Generate the Autograder.io CLI JSON Schema:\n```\nag write-schema\n```\nThis will create a file called `autograder_io_cli_schema.json` in the current working directory.\n3. Add the following to your VSCode settings.json:\n```\n \"yaml.schemas\": {\n \"/path/to/autograder_io_cli_schema.json\": [\n \"agproject.yml\",\n \"*.agproject.yml\",\n \"agproject.*.yml\"\n ]\n }\n```\nThis will cause the YAML plugin to recognize `agproject.yml` and `*.agproject.yml` files as using the Autograder.io CLI schema.\n\nNOTE: The plugin flags an empty `settings` key as an error.\nLeaving `settings` blank is allowed and will use the default field values.\n\nPull requests are welcome that add instructions for setting up autocomplete on other editors.\n\n### Common Usage\n#### New Project From Scratch\nUse the following command to create a project config file with default values.\nReplace `'My Course' Fall 2025` with the name, term, and year of your course.\nReplace `'My Project'` with the name of your assignment.\nThe course you identify by name, semester, and year must already exist before you can save the project.\nThis only creates the config file locally, it does not save any changes to Autograder.io.\n```\nag project init 'My Course' Fall 2025 'My Project'\n```\n\nThis will create a configuration file `agproject.yml`.\nYou can choose a different name with the `--config_file` flag.\n\nThis CLI attempts to detect your local timezone.\nYou can change the `timezone` field in the config file if you wish to use a different timezone.\n\nSee [Save a Project](Save-a-Project) to save your configured project\n\n#### Download (Load) an Existing Project\nThis command loads settings for an existing project and writes the settings to a file.\nIt also downloads instructor files associated with that project.\nFor example:\n```\nag project load 'My Course' Fall 2025 'My Project' myproject.agproject.yml\n```\nwill download the specified project and save its configuration to the file `myproject.agproject.yml`.\nInstructor files for that project will be saved in the same directory as the config file.\nThat is, if you specify `../some/path/myproject.agproject.yml`, the instructor files will be saved to `../some/path/`.\n\n#### Save a Project\nTo save your configured project to Autograder.io, run the following command from the same directory as the config file:\n```\nag project save\n```\n\nYou can specify a different config file with the `--config_file` flag.\n\n## FAQ and Tips\n### Repeating Test Cases\nThe config format provides a \"repeat\" mechanism for defining groups of similar test cases in a compact way.\nFor example:\n```\nproject:\n # Project information and settings\n # ...\n test_suites:\n - name: Python Unit Tests\n test_cases:\n # $test_label is a user-chosen placeholder.\n # The leading $ is not required but helps readability.\n - name: Test $test_label\n cmd: python3 -m unittest -k $test_name\n return_code:\n expected: zero\n feedback:\n normal: pass/fail+timeout\n final_graded_submission: pass/fail+timeout\n # Define substitutions for our placeholders\n repeat:\n - $test_label: Normal 1\n $test_name: normal1\n # Specify specific values for this test case.\n _override:\n return_code:\n points: 2\n - $test_label: Edge 1\n $test_name: edge1\n _override:\n return_code:\n points: 3\n```\n\nSaving this configuration will create two test cases with the same feedback and expected return code settings, but with different names, commands, and point values.\n\n### Default Values\nSince there is not a perfect one-to-one mapping between CLI project configuration options and API fields, there are some cases where the CLI and API have different default values.\nRemoving a field from the config file and then saving the project will reset that value to its CLI default.\n\nThe `ag project init` command creates a config file with all fields present and set to their CLI defaults.\nIn contrast, the `ag project load` command creates a config file that only contains non-default values.\n\n### Feedback Presets\nThe config file supports several presets for test case feedback settings.\nYou can also define your own feedback presets under the `feedback_presets` key (for single command tests or the commands in multi-command tests) and the `feedback_presets_test_suite_setup` key (for test suite setup commands).\nThe config file created by `ag project init` contains definitions for several built-in presets.\nDo not edit the contents presets.\nHowever, once you are familiar with the CLI's built-in presets, you may remove them from the config file.\nThe CLI will recognize them even if they are not present in the config file.\n\n### Sandbox Images\nThe CLI does not yet support building sandbox images.\nPlease build your images through the Autograder.io website.\nIn test suite definitions in the config file, you may specify the name of any sandbox image you've built for the course on Autograder.io.\n\n### Deleting Entries\nThe CLI currently does NOT support deleting entries such as instructor files, expected student files, or test cases.\nRemoving these entries from the config file and saving the project will NOT delete those entries.\nIf you need to delete those entires, please do so through the Autograder.io website.\n\n### Renaming Entries\nThe CLI does not yet support renaming entries.\nChanging the name of an entry will cause a new entry to be created.\nPlease rename entries through the Autograder.io website.\nWe are currently considering solutions for renaming.\nOur goal is to balance ease-of-use, predictability, and complexity of the implementation.\nPlease let us know if you have suggestions by commenting on [this issue](https://github.com/eecs-autograder/autograder-cli/issues/6).\n\n## Versioning\nThis package uses calendar versioning following [Python conventions](https://packaging.python.org/en/latest/discussions/versioning/), with version numbers of the form `yyyy.mm.X`, where `X` is for minor versions.\nFor example: `2024.8.0` corresponds to August 2024.\nWe also make use of pre-release tags such as `.devX`.\n\nThe year and month of the release specify the earliest version of the Autograder.io API this package is compatible with.\nHowever, the minor version number **does not correspond** to Autograder.io's minor version numbers.\nAlso note that backwards-incompatible changes to the Autograder.io API may make future versions of that API incompatible with earlier versions of the CLI.\n\n### Development & Release Branches: Protocols and Workflow\nThis section is intended for developers.\n\n#### \"develop\" branch\nUse feature branches for all changes, and make a pull request against the `develop` branch.\nThe `develop` branch is for changes based on the `develop` branch of the `autograder-server` repo (which is a submodule of this repo found at `tests/local_stack/autograder-server`).\nUpdate the submodule `develop` branch when starting work on a feature that depends on new `autograder-server` commits.\nUse the following steps on your feature branch:\n```\n# Fetch latest submodule commits\ngit submodule update --remote\n# git status should show new commits in the submodule\ngit status\ngit add tests/local_stack/autograder-server\ngit commit -m \"Update submodule\"\n```\n\n#### \"release-*\" branches\nName release branches as `release-YYYY.MM.x`, replacing YYYY with the full year and MM with the zero padded month (e.g., `release-2024.08.x`).\nThe month format differs from the Python package versioning (e.g., `2024.8.x`) so that branches are sorted properly.\n\nDo NOT merge or rebase directly between the develop and release branches.\nOnce a release branch is created, it should only be updated with feature- or bugfix-style branches.\nWe generally recommend a squash-and-merge for these types of PRs.\nAfter the squashed feature/bugfix branch is merged into a release branch, cherry-pick the squashed commit on top of `develop` and open a pull request to merge the changes into `develop`.\n\nRelease branches should keep the corresponding `autograder-server` submodule release branch up to date.\nFollow the same protocol as for the `develop` branch.\n\nFor the first release of this library (2024.8), there will be a time period of adding features to the release branch until we support all project configuration options.\nAt time of writing, handgrading options are the main missing piece.\n\nThe version of `README.md` (this file) on the `develop` branch is the source of truth.\nUpdate this file on release branches just before publishing a release.\nIf instructions differ across releases, include both, and label which version the instructions apply to.\n\n#### Publishing a release\nTo create a github release, tag the latest commit on the release branch.\nFor example, to create the first non-dev 2024.8 release, we'd run:\n```\ngit checkout release-2024.08.x\ngit tag 2024.8.0\ngit push --tags\n```\nCI will build and test the package, publish to pypi, and create a GitHub release.\n\n## Dev Setup\n### Clone the Repository\n```\ngit clone --recursive git@github.com:eecs-autograder/autograder-cli.git\ncd autograder-cli\n```\n\nIf you omitted the `--recursive` flag, initialize the submodule with:\n```\ngit submodule update --init\n```\n\n### Install Dependencies\nCreate and activate a virtual environment:\n```\npython3.10 -m venv venv\nsource venv/bin/activate\n```\n\nInstall package dependencies and install the autograder-cli as a local editable package:\n```\npip install pip-tools\n./dev_scripts/install_deps.sh\n```\n\nInstall [dyff](https://github.com/homeport/dyff) for comparing yaml files in test cases:\n```\ncurl --silent --location https://git.io/JYfAY | bash\n```\n\n### Build the Local autograder-server Stack\nBuild and start the stack:\n```\n./dev_scripts/local_stack.sh build\n./dev_scripts/local_stack.sh up -d\n```\n`./dev_scripts/local_stack.sh` is an alias for a docker-compose command.\n\nGenerate the gpg secrets for the autograder-server stack:\n```\npython -m pip install Django==3.1 python-gnupg\ncd tests/local_stack/autograder-server && python3 generate_secrets.py\ncd -\n```\n\n[Running the tests](Tests) will finish preparing the stack by applying migrations and clearing the database.\n\n### Linters\nRun isort, black, pycodestyle, pydocstyle, and pyright to check for style, formatting, and type issues:\n```\n./dev_scripts/lint.sh\n```\nPython code should be formatted using isort and black.\n\n### Tests\nBuild and start the local stack as described above, then run the tests with:\n```\n./dev_scrips/test.sh\n```\nThis script does a few preparation steps and then invokes pytest.\nExtra command line arguments to `test.sh` are passed through to pytest, e.g.:\n```\n./dev_scripts/test.sh -k test_project_init\n```\n\nThis project uses pytest as its test runner.\nMost of the test cases are currently \"roundtrip\" tests that save and load a configuration.\nTo generate a new roundtrip test, run:\n```\n./dev_scripts/new_roundtrip_test.sh {test name}\n```\n\nThe test name can include directories (e.g., ag_test_suite/setup_cmd).\nThis will initialize a roundtrip test in tests/roundtrip/{test name}.test.\nRoundtrip tests consist of the following steps:\n1. Save the project found in `{test name}/agproject.create.yml`.\n2. Load that project and compare the loaded version with `{test name}/agproject.create.expected.yml`.\n3. Save the project found in `{test name}/agproject.update.yml`. (this is intended to be the same project that was created in step one, but with some fields changed)\n4. Load that project and compare the loaded version with `{test name}/agproject.update.expected.yml`.\n\nWhen testing deadline formats (e.g., fixed cutoff, relative cutoff), you can specify which format to load deadlines into in the file `{test name}/deadline_cutoff_preference`.\n\nIn the `.expected.yml` files, if you haven't set any values in `project.settings`, you will need to set `project.settings` to an empty dictionary.\nWe haven't made the `new_roundtrip_test.sh` script make this change because it serves as a way to have new test cases fail until they are edited.\n\n### The HTTPClient\nThe `HTTPClient` class is a starting point for sending custom requests in Python applications.\n```\nimport json\nfrom ag_contrib.http_client import HTTPClient, check_response_status\n\nclient = HTTPClient.make_default()\nresponse = client.get('/api/users/current/')\ncheck_response_status(response)\nprint(json.dumps(response.json(), indent=4))\n```\n\n#### HTTP Client Command-Line Interface\nThis library provides a minimal command-line interface for sending custom HTTP requests to the Autograder.io API.\nRun `ag http --help` for more details.\n",
"bugtrack_url": null,
"license": null,
"summary": "A command-line http client and other utilities for using the autograder.io API.",
"version": "2024.8.0rc1",
"project_urls": {
"Homepage": "https://github.com/eecs-autograder/autograder-cli",
"Issues": "https://github.com/eecs-autograder/autograder-cli/issues"
},
"split_keywords": [
"autograder",
" autograder.io"
],
"urls": [
{
"comment_text": null,
"digests": {
"blake2b_256": "bf280d1e2f3e93b341a0f4e4b5e289f3120ee1859a2fa0ed09185fb055b96674",
"md5": "d34280bbee644e7f9f0dd4e4bc9eda67",
"sha256": "fee8580740b113411a8abe7f21114de12432643443f873c2a5de218d824746f7"
},
"downloads": -1,
"filename": "autograder_cli-2024.8.0rc1-py3-none-any.whl",
"has_sig": false,
"md5_digest": "d34280bbee644e7f9f0dd4e4bc9eda67",
"packagetype": "bdist_wheel",
"python_version": "py3",
"requires_python": ">=3.10",
"size": 67090,
"upload_time": "2025-08-07T15:39:02",
"upload_time_iso_8601": "2025-08-07T15:39:02.060409Z",
"url": "https://files.pythonhosted.org/packages/bf/28/0d1e2f3e93b341a0f4e4b5e289f3120ee1859a2fa0ed09185fb055b96674/autograder_cli-2024.8.0rc1-py3-none-any.whl",
"yanked": false,
"yanked_reason": null
},
{
"comment_text": null,
"digests": {
"blake2b_256": "055bd15291b2c4a7e8e94f06c53f4371e16e1b8868fc9b767db16ced1b2e89b4",
"md5": "d583511a4089029dcb74588272c2e803",
"sha256": "eb8fd35158fc42e9d0284baa58ba423649b60c90d61632022fff55081dd30863"
},
"downloads": -1,
"filename": "autograder_cli-2024.8.0rc1.tar.gz",
"has_sig": false,
"md5_digest": "d583511a4089029dcb74588272c2e803",
"packagetype": "sdist",
"python_version": "source",
"requires_python": ">=3.10",
"size": 110493,
"upload_time": "2025-08-07T15:39:03",
"upload_time_iso_8601": "2025-08-07T15:39:03.893051Z",
"url": "https://files.pythonhosted.org/packages/05/5b/d15291b2c4a7e8e94f06c53f4371e16e1b8868fc9b767db16ced1b2e89b4/autograder_cli-2024.8.0rc1.tar.gz",
"yanked": false,
"yanked_reason": null
}
],
"upload_time": "2025-08-07 15:39:03",
"github": true,
"gitlab": false,
"bitbucket": false,
"codeberg": false,
"github_user": "eecs-autograder",
"github_project": "autograder-cli",
"travis_ci": false,
"coveralls": false,
"github_actions": true,
"requirements": [
{
"name": "annotated-types",
"specs": [
[
"==",
"0.6.0"
]
]
},
{
"name": "certifi",
"specs": [
[
"==",
"2023.11.17"
]
]
},
{
"name": "charset-normalizer",
"specs": [
[
"==",
"3.3.2"
]
]
},
{
"name": "dnspython",
"specs": [
[
"==",
"2.4.2"
]
]
},
{
"name": "email-validator",
"specs": [
[
"==",
"2.1.0.post1"
]
]
},
{
"name": "idna",
"specs": [
[
"==",
"3.6"
]
]
},
{
"name": "pydantic",
"specs": [
[
"==",
"2.10.3"
]
]
},
{
"name": "pydantic-core",
"specs": [
[
"==",
"2.27.1"
]
]
},
{
"name": "python-dateutil",
"specs": [
[
"==",
"2.9.0.post0"
]
]
},
{
"name": "pyyaml",
"specs": [
[
"==",
"6.0.1"
]
]
},
{
"name": "requests",
"specs": [
[
"==",
"2.31.0"
]
]
},
{
"name": "six",
"specs": [
[
"==",
"1.16.0"
]
]
},
{
"name": "typing-extensions",
"specs": [
[
"==",
"4.12.2"
]
]
},
{
"name": "tzlocal",
"specs": [
[
"==",
"5.2"
]
]
},
{
"name": "urllib3",
"specs": [
[
"==",
"2.1.0"
]
]
}
],
"lcname": "autograder-cli"
}
JSON
