# Contributing to `idfkit`

Contributions are welcome, and they are greatly appreciated!
Every little bit helps, and credit will always be given.

You can contribute in many ways:

# Types of Contributions

## Report Bugs

Report bugs at https://github.com/idfkit/idfkit/issues

If you are reporting a bug, please include:

- Your operating system name and version.
- Any details about your local setup that might be helpful in troubleshooting.
- Detailed steps to reproduce the bug.

## Fix Bugs

Look through the GitHub issues for bugs.
Anything tagged with "bug" and "help wanted" is open to whoever wants to implement a fix for it.

## Implement Features

Look through the GitHub issues for features.
Anything tagged with "enhancement" and "help wanted" is open to whoever wants to implement it.

## Write Documentation

idfkit could always use more documentation, whether as part of the official docs, in docstrings, or even on the web in blog posts, articles, and such.

### Documentation Code Snippets

Python code blocks in the MkDocs documentation are stored as standalone `.py` files under `docs/snippets/`.
This lets ruff and pyright lint them alongside the rest of the codebase.

Each snippet file has two parts separated by section markers:

```python
from __future__ import annotations

from idfkit import IDFDocument

model: IDFDocument = ...  # type: ignore[assignment]
# --8<-- [start:example]
for zone in model["Zone"]:
    print(zone.name)
# --8<-- [end:example]
```

- **Preamble** (above `[start:example]`): imports and type stubs that satisfy pyright.
  Hidden from the rendered docs.
- **Example body** (between the markers): the code readers see in the documentation.

The corresponding markdown file includes only the example section:

````markdown
```python
--8<-- "docs/snippets/getting-started/quick-start/query_objects.py:example"
```
````

#### Adding a new snippet

1. Create a `.py` file under `docs/snippets/`, mirroring the docs directory structure
   (e.g., `docs/simulation/running.md` → `docs/snippets/simulation/running/<name>.py`).
2. Write the example code between `# --8<-- [start:example]` and `# --8<-- [end:example]` markers.
3. Above the start marker, add `from __future__ import annotations`, any imports needed
   by the example, and type stubs for variables the snippet uses but doesn't define:
   ```python
   model: IDFDocument = ...  # type: ignore[assignment]
   ```
4. In the markdown file, reference the snippet with the `:example` suffix:
   ````markdown
   ```python
   --8<-- "docs/snippets/path/to/snippet.py:example"
   ```
   ````
5. Run `make check` to verify ruff and pyright pass, and `uv run mkdocs build --strict`
   to verify the docs render correctly.

If a code block is intentionally invalid Python (e.g., bare `await`, pseudo-code,
or an incomplete function signature), leave it as an inline markdown code block
instead of extracting it into a snippet file.

## Submit Feedback

The best way to send feedback is to file an issue at https://github.com/idfkit/idfkit/issues.

If you are proposing a new feature:

- Explain in detail how it would work.
- Keep the scope as narrow as possible, to make it easier to implement.
- Remember that this is a volunteer-driven project, and that contributions
  are welcome :)

# Get Started!

Ready to contribute? Here's how to set up `idfkit` for local development.
Please note this documentation assumes you already have `uv` and `Git` installed and ready to go.

1. Fork the `idfkit` repo on GitHub.

2. Clone your fork locally:

```bash
cd <directory_in_which_repo_should_be_created>
git clone git@github.com:YOUR_NAME/idfkit.git
```

3. Now we need to install the environment. Navigate into the directory

```bash
cd idfkit
```

Then, install and activate the environment with:

```bash
uv sync
```

4. Install pre-commit to run linters/formatters at commit time:

```bash
uv run pre-commit install
```

5. Create a branch for local development:

```bash
git checkout -b name-of-your-bugfix-or-feature
```

Now you can make your changes locally.

6. Don't forget to add test cases for your added functionality to the `tests` directory.

7. When you're done making changes, check that your changes pass the formatting tests.

```bash
make check
```

Now, validate that all unit tests are passing:

```bash
make test
```

8. Before raising a pull request you should also run tox.
   This will run the tests across different versions of Python:

```bash
tox
```

This requires you to have multiple versions of python installed.
This step is also triggered in the CI/CD pipeline, so you could also choose to skip this step locally.

9. Commit your changes and push your branch to GitHub:

```bash
git add .
git commit -m "Your detailed description of your changes."
git push origin name-of-your-bugfix-or-feature
```

10. Submit a pull request through the GitHub website.

# Pull Request Guidelines

Before you submit a pull request, check that it meets these guidelines:

1. The pull request should include tests.

2. If the pull request adds functionality, the docs should be updated.
   Put your new functionality into a function with a docstring, and add the feature to the list in `README.md`.
