|
| 1 | +# Contributing to AST-Healer |
| 2 | + |
| 3 | +Thanks for your interest in contributing. This document covers how to set up a development environment, coding standards, and how to submit a pull request. |
| 4 | + |
| 5 | +--- |
| 6 | + |
| 7 | +## Development setup |
| 8 | + |
| 9 | +```bash |
| 10 | +git clone https://github.com/imohitseth/AST-Healer.git |
| 11 | +cd AST-Healer |
| 12 | + |
| 13 | +python -m venv .venv |
| 14 | +source .venv/bin/activate # Windows: .venv\Scripts\Activate.ps1 |
| 15 | + |
| 16 | +pip install -r requirements.txt |
| 17 | +pip install ruff # linter used in CI |
| 18 | + |
| 19 | +cp .env.example .env # add your GEMINI_API_KEY |
| 20 | +``` |
| 21 | + |
| 22 | +--- |
| 23 | + |
| 24 | +## Running the tests |
| 25 | + |
| 26 | +```bash |
| 27 | +PYTHONPATH=. pytest tests/ -v |
| 28 | +``` |
| 29 | + |
| 30 | +The mock tests in `tests/` do not require a live API key — they operate on the bundled `mock_code.py` and `mock_run.py` targets. Tests that invoke the Gemini agent are skipped automatically when `GEMINI_API_KEY` is not set. |
| 31 | + |
| 32 | +--- |
| 33 | + |
| 34 | +## Coding standards |
| 35 | + |
| 36 | +- **Python 3.11+** — use `asyncio`, `ast`, and standard library features where possible before reaching for third-party packages. |
| 37 | +- **Linting** — run `ruff check . --select E,W,F --ignore E501` before pushing. CI will fail on lint errors. |
| 38 | +- **Type hints** — add type annotations to all new functions and method signatures. |
| 39 | +- **Docstrings** — one-line summary for simple functions; full Args/Returns for anything public-facing. |
| 40 | +- No new dependencies should be added to `requirements.txt` without discussion in an issue first. |
| 41 | + |
| 42 | +--- |
| 43 | + |
| 44 | +## Submitting a pull request |
| 45 | + |
| 46 | +1. Fork the repo and create a branch from `main`: `git checkout -b feat/your-feature-name` |
| 47 | +2. Make your changes. Add or update tests as needed. |
| 48 | +3. Run `ruff check .` and `pytest tests/ -v` locally — both must pass. |
| 49 | +4. Open a PR against `main` with a clear description of what changed and why. |
| 50 | +5. Reference any related issues with `Closes #N`. |
| 51 | + |
| 52 | +--- |
| 53 | + |
| 54 | +## Reporting bugs |
| 55 | + |
| 56 | +Open a GitHub Issue with: |
| 57 | +- Python version and OS |
| 58 | +- Steps to reproduce |
| 59 | +- Full traceback output |
| 60 | +- The target file that caused the failure (if shareable) |
| 61 | + |
| 62 | +--- |
| 63 | + |
| 64 | +## Feature requests |
| 65 | + |
| 66 | +Open an issue with the `enhancement` label. Describe the use case, not just the implementation — it's easier to discuss tradeoffs that way. |
0 commit comments