GitLocker: The Coding Marketplace

Description:

pytestaoc 1.23.4

pytest-aoc
This pytest plugin downloads puzzle inputs for Advent of Code and
synthesizes fixtures that you can use in your tests.

Does this DDoS the adventofcode.com website?
This plugin tries pretty hard to not hit the adventofcode.com website unless
absolutely necessary. When the test session starts, the puzzle inputs that
should be available are calculated based on the system clock. For every input
that should be available (after 05:00:00 GMT), if no corresponding text file is
found on disk, it gets downloaded and saved, if the HTTP status code is 200 OK.
The personal downloaded puzzle inputs should be committed to source control, so
that pytest doesn't need to hit the adventofcode.com API to run the tests in
another environment.
New in version 1.22.0: the code also sleeps (2.5 seconds by default) after
hitting the server. This can be disabled if you have leaderboard aspirations,
but really, do you have time to be practising TDD in that case?
Installing and configuring
Installing is easy: python -m pip install pytest-aoc. Next you will need to configure
two things: for which event (year) the plugin should download inputs, and a
valid session cookie. These are normally valid for about a month or so.
To set the year, put it in setup.cfg:
[tool:pytest]
aoc_year = 2018

Better yet, ditch setup.cfg and use pyproject.toml:
[tool.pytest.ini_options]
aoc_year = 2023

Then, put a valid session ID in a file named .cookie and also name this file
in your .gitignore.
With these two things in place, when running pytest, this plugin will download
any missing inputs, and generate pytest fixtures that you can use in your test
functions, see 'Using' and 'Fixtures', below.
Using
With this plugin properly configured, you can write tests like this:
def test_01a(day01_numbers):
assert sum(day01_numbers) == 123

Here, the parameter day01_numbers is a fixture that contains the numbers on
each line in the file input/day01.txt.
Fixtures
These fixtures are synthesized for each available day. They're not executed
until you ask for them in a test.

fixture
example
help

dayNN_text
"eggs"
The text in the input file, but stripped of any leading and trailing whitespace.

dayNN_raw
"eggs\n"
The raw text in the input file.

dayNN_lines
["spam", "eggs", "albatross"]
A list of stripped lines.

dayNN_numbers
[1, 1, 2, 3, 5, 8]
A list of numbers.

dayNN_number
5
A single number.

dayNN_grid
[["spam", "eggs"], ["ham", "albatross"]]
A list of lists, representing a grid of textual values.

dayNN_number_grid
[[8, 1, 6], [3, 5, 7], [4, 9, 2]]
A list of lists, representing a grid of numbers.

Command-line and configuration options
You can pass the options from the command line or set them in setup.cfg. The
command line takes precedence.

command line flag
config file option
help

--aoc-year
aoc_year
The year for which to download puzzle inputs. (Mandatory)

--aoc-session-id
-
The session ID to use for requesting puzzle inputs. This one has no equivalent setup.cfg key; that's a security feature. (Optional)

--aoc-session-file
aoc_session_file
The file from which to read the session ID. (Optional; default .cookie)

--aoc-input-dir
aoc_input_dir
The directory in which inputs are stored. Will be created if it doesn't exist. (Optional; default input)

--aoc_sleep_time
aoc_sleep_time
Time to sleep after downloading puzzle input, set to 0 to skip sleeping. (Optional; default 2.5)

Developing / testing
Set environment variables using . .envrc or by automatically loading them
using direnv allow.
Create a virtualenv named env and install an editable version of this package
with all extra development dependencies:
python -m venv env
python -m pip install -U -e .[dev,test]

Run tests directly, to test against the current Python, or via tox to test
against multiple Python versions:
python -m pytest
python -m tox run

Releasing
The procedure goes like this:

Set a git tag to let setuptools-scm derive a version from it
Use build to package up the sdist and the wheel
Upload sdist and wheel to Pypi using twine
Create a release on Gitlab using gitlab-cli

Tagging the release commit
(Optional) Tag the release version (or it will be a dev release on the next version as
derived by setuptools-scm) where x.y.z is the version:
git tag -a x.y.z

...or even use bash history to refer to the third argument (:3) of the current command (!#):
git tag -a x.y.z -m !#:3

But: prefer to write the release notes in here, so don't actually use -m for
non-rc releases.
Check that the version is actually sane:
python -m setuptools_scm

Build the package files
Bake an sdist and a wheel into a clean dist directory:
rm -f dist/*
python -m build

Upload to PyPI
Upload the goods to PyPI:
python -m twine upload dist/*

(I tried the --sign option once, got an email from PyPI saying GPG signatures
are unsupported on PyPI, and am now reconsidering some very recent life
choices. Dammit, I went decades without needing a PGP key,
could I not have continued to do without?)
Create release on Gitlab
Upload the goods to Gitlab, where again x.y.z is the version:
git push gitlab main --tags
glab release create x.y.z dist/*.{tar.gz,whl}