Board Game Recommender
Documentation: https://recommend-games.github.io/board-game-recommender
Source Code: https://github.com/recommend-games/board-game-recommender
PyPI: https://pypi.org/project/board-game-recommender/
Board game recommendation engine.
Installation
pip install board-game-recommender
Development
- Clone this repository
- Requirements:
- Poetry
- Python 3.12+
- Create a virtual environment and install the dependencies
poetry install
- Activate the virtual environment
poetry shell
Testing
pytest
Documentation
The documentation is automatically generated from the content of the docs directory and from the docstrings of the public signatures of the source code. The documentation is updated and published as a Github Pages page automatically as part each release.
Releasing
Trigger the Draft release workflow (press Run workflow). This will update the changelog & version and create a GitHub release which is in Draft state.
Find the draft release from the GitHub releases and publish it. When a release is published, it'll trigger release workflow which creates PyPI release and deploys updated documentation.
Pre-commit
Pre-commit hooks run all the auto-formatting (ruff format), linters (e.g. ruff and mypy), and other quality
checks to make sure the changeset is in good shape before a commit/push happens.
You can install the hooks with (runs for each commit):
pre-commit install
Or if you want them to run only for each push:
pre-commit install -t pre-push
Or if you want e.g. want to run all checks manually for all files:
pre-commit run --all-files
Releasing manually
If you'd rather not use GitHub Actions or the gh CLI, you can cut a release entirely from the command line:
# 1. Bump version (patch|minor|major|prepatch|preminor|premajor|prerelease, or explicit e.g. 1.2.3)
poetry version patch
VERSION=$(poetry version --short)
# 2. Update changelog
poetry run kacl-cli release "$VERSION" --modify --auto-link
# 3. Commit the version bump
git add CHANGELOG.md pyproject.toml
git commit -m "Release $VERSION"
# 4. Tag and push. `master` tracks GitLab, but the docs are published from
# GitHub, so both remotes need the commit and the tag.
git tag "$VERSION"
git push gitlab master
git push gitlab "$VERSION"
git push github master
git push github "$VERSION"
# 5. Build and publish to PyPI (needs a token, e.g. via a PYPI_TOKEN env var)
poetry config pypi-token.pypi "$PYPI_TOKEN"
poetry publish --build
# 6. Deploy docs to GitHub Pages
poetry run mkdocs gh-deploy --force --remote-name github
Three things worth knowing:
- Tags carry no
vprefix —4.0.0, notv4.0.0. That is what the draft release workflow creates, and what the changelog's auto-generated links expect. The olderv3.6.0-style tags predate this convention. mkdocs gh-deploypushes to a remote calledoriginby default, which this repository does not have, hence--remote-name github.poetry versiononly editspyproject.toml.poetry.lockrecords a hash of the dependencies rather than the project's own version, so it does not need committing.
Note that no GitHub Release object gets created this way — only the PyPI package and docs. Steps 4 and 6 use plain git push (not the GitHub API), so they work without gh.
This project was generated using the wolt-python-package-cookiecutter template.