|
| 1 | +# Contributing |
| 2 | + |
| 3 | +Hello human and AI contributors, this document exists to help you understand the project and set some rules for contributions. |
| 4 | + |
| 5 | +## Contribution Workflow |
| 6 | + |
| 7 | +Before opening a pull request, search existing issues and PRs to avoid duplicate work. |
| 8 | +Keep each PR focused on one feature, bug fix, or vendor update. |
| 9 | +Avoid mixing unrelated Python changes, generated binding updates, documentation edits, and `vendor/llama.cpp` changes unless they are required for the same fix. |
| 10 | + |
| 11 | +Describe what changed, why it changed, and how it was tested. |
| 12 | +Link relevant issues, include any required build flags or hardware assumptions, and add a `CHANGELOG.md` entry for user-visible fixes or features (see `CHANGELOG.md` for examples). |
| 13 | + |
| 14 | +BREAKING CHANGES WILL ALMOST CERTAINLY BE REJECTED OR REFACTORED. |
| 15 | + |
| 16 | +## PR Titles and Changelog Entries |
| 17 | + |
| 18 | +Use PR titles in the form `<tag>: <title>`, with an optional scope when it adds clarity: `feat: add X`, `fix(server): handle Y`, `fix(ci): repair Z`, or `chore: bump version to N`. |
| 19 | +Prefer tags already used in the project history, such as `feat`, `fix`, `chore`, `ci`, `docs`, and `refactor`. |
| 20 | + |
| 21 | +Add changelog entries under `## [Unreleased]` using the PR title followed by `by @contributor in #1234`. |
| 22 | + |
| 23 | +```md |
| 24 | +- feat(server): add support for X by @contributor in #1234 |
| 25 | +- fix(ci): repair Y wheel builds by @contributor in #1234 |
| 26 | +``` |
| 27 | + |
| 28 | +## Local Development |
| 29 | + |
| 30 | +Prerequisites: Python 3.8+, CMake 3.21+, a C/C++ compiler, and Git submodules. |
| 31 | +From a fresh checkout of the repository, initialize submodules and create a virtual environment: |
| 32 | + |
| 33 | +```bash |
| 34 | +git submodule update --init --recursive |
| 35 | +python3 -m venv .venv |
| 36 | +source .venv/bin/activate |
| 37 | +python -m pip install --upgrade pip |
| 38 | +make deps |
| 39 | +make build |
| 40 | +``` |
| 41 | + |
| 42 | +Run tests and lint checks before submitting changes: |
| 43 | + |
| 44 | +```bash |
| 45 | +make test |
| 46 | +make lint |
| 47 | +``` |
| 48 | + |
| 49 | +Use backend-specific build targets when validating native acceleration or backend-specific fixes, for example `make build.openblas`, `make build.cuda`, `make build.metal`, or `make build.vulkan`. |
| 50 | + |
| 51 | +## Testing Expectations |
| 52 | + |
| 53 | +Add or update tests for behavior changes or fixing regressions. |
| 54 | +The test suite uses pytest and lives under `tests/`; name files `test_*.py` and test functions `test_*`. |
| 55 | + |
| 56 | +For changes involving native backends, model behavior, performance, or platform compatibility, document the environment used for validation in the PR. |
| 57 | +If a change cannot be covered by automated tests, include a short manual validation recipe instead. |
| 58 | + |
| 59 | +## Code Style |
| 60 | + |
| 61 | +Python code is formatted with Ruff using an 88-character line length. |
| 62 | +Run `make format` to apply automatic fixes and `make lint` to check formatting and lint rules. |
| 63 | + |
| 64 | +Use 4-space indentation, `snake_case` for functions and variables, `PascalCase` for classes, and `UPPER_CASE` for constants. |
| 65 | +Follow existing patterns when touching ctypes bindings or server APIs, and avoid adding dependencies unless they are necessary for the feature or fix. |
| 66 | + |
| 67 | +## Documentation Style |
| 68 | + |
| 69 | +Write Markdown with one sentence or core idea per physical line to keep diffs focused and easier to review. |
| 70 | +Do not manually wrap lines at a fixed column width. |
| 71 | +Keep `README.md` focused on user-facing setup and usage; link to this guide for contribution workflow details rather than duplicating them. |
| 72 | + |
| 73 | +## Project Layout |
| 74 | + |
| 75 | +The Python package lives in `llama_cpp/`, with tests in `tests/` and examples in `examples/`. |
| 76 | +Documentation lives in `docs/` and is built with `mkdocs.yml`. |
| 77 | +The `vendor/llama.cpp/` directory is a Git submodule containing the upstream llama.cpp sources used by the bindings. |
0 commit comments