emilkloeden/aoc-cli

A command-line interface for expediting advent-of-code

aoc-cli

An opinionated scaffolder for Advent of Code

Installation

pip install aoc-cli

Optionally install language-specific plugins such as pip install aoc-cli-deno.

Usage

Scaffold a project with aoc init --language <python> --year <current year if december, else previous year> --location .

All other subcommands are directory aware:

*Note: plugins (specified with the --language flag) may alter the functionality below but in general...

aoc get downloads the input for the day aoc run <part> executes the function specified in (1 or 2) file for the day aoc submit <part> executes the function specified in (1 or 2) file for the day, then submits the answer to the form aoc open opens the current day in the browser

aoc-cli's Issues

Add testing

Tests are noticeably absent at this point in time.

Also to add, test coverage and pre-merge checks.

Project logo

Every respectable project requires a logo.

Automated builds using GitHub Actions

The steps to mark a new release are tedious and error prone and currently consist of

• Bumping version in init.py (can we simply delete this?)
• Bumping version in pyproject.toml
• (Potentially) Incrementing the aoc-cli-python dependency
• running rm -recurse -force ./dist (not sure this is necessary
• running py -m build
• running py -m twine upload dist/* (requires TWINE_USERNAME and TWINE_PASSWORD to be set)

Completing this issue would mean a push of a tag to GitHub would trigger a release to PyPI.

Of course the project should also have some tests

Allow plugins to specify folder structure using configuration file instead of code

So far all my plugins generate a tree like this:

-- year
---- language
------ day

What if a plugin author wanted to specify a different configuration, could this be done simply in a config.json file or similar (instead of overriding Initialiser.initialise?

Improve documentation

The README could use a lot of work to make it more approachable.

The project has two core audiences - users and contributors/plugin authors, documentation should be written with these two audiences in mind.