Contribution Guidelines

We welcome any kind of contribution to our software, from a simple comment or question to a full-fledged pull request.

A contribution can be one of the following cases:

You have a question;
You think you may have found a bug (including unexpected behavior);
You want to change the code base (e.g., to fix a bug, add a new feature, or update documentation).

The sections below outline the steps in each case.

You have a question

Use the search functionality here to see if someone already filed the same issue;
If your issue search did not yield any relevant results, make a new issue;
Apply the “Question” label; apply other labels when relevant.

You think you may have found a bug

Use the search functionality here to see if someone already filed the same issue;
If your issue search does not yield any relevant results, make a new issue, providing enough information to the rest of the community to understand the cause and context of the problem. Depending on the issue, you may want to include:
- the SHA hashcode of the commit that is causing your problem;
- some identifying information (name and version number) for dependencies you’re using;
- information about the operating system;
Apply relevant labels to the newly created issue.

You want to make some kind of change to the code base

(Important) Announce your plan to the rest of the community before you start working. This announcement should be in the form of a (new) issue;
(Important) Wait until some kind of consensus is reached about your idea being a good idea;
If needed, fork the repository to your own Github profile and create your own feature branch off of the latest main commit. While working on your feature branch, make sure to stay up to date with the main branch by pulling in changes, possibly from the ‘upstream’ repository (follow the instructions here and here);
Make sure the existing tests still work by following the instructions in Run the test suite;
Add your own tests (if necessary);
If you added your own tests, make sure they pass by following the instructions in Run the test suite;
Lint your changes by following the instructions in Lint;
If your contribution is a performance enhancement, make sure to include benchmarks. See Benchmarking for more information;
Update or expand the documentation;
Make sure the documentation builds without errors by following the instructions in Build the documentation;
Check that you can build the package locally and that it passes twine check. See Build from source for more information;
Push your feature branch to (your fork of) the IKPLS repository on GitHub;
Create the pull request, e.g. following the instructions here.

If you feel like you’ve made a valuable contribution, but you don’t know how to write or run tests for it or generate the documentation, don’t let this discourage you from making the pull request; we can help you! Just submit the pull request, but remember that you might be asked to append additional commits to your pull request.

Build from source

IKPLS uses uv to manage its dependencies and packaging. To build the package from source, follow these steps:

Clone the repository:

git clone https://github.com/Sm00thix/IKPLS.git

Change to the repository directory:
```
cd IKPLS
```

Install uv, e.g.:

curl -LsSf https://astral.sh/uv/install.sh | sh

Build the package. uv builds in an isolated environment, so no separate dependency-install step is needed:
```
uv build
```
Check the package with twine:
```
uvx twine check dist/*
```

If you change the project’s dependencies in pyproject.toml, refresh the committed lockfile and commit the updated uv.lock:

uv lock

Run the test suite

To run the test suite, follow these steps:

Install uv, e.g.:

curl -LsSf https://astral.sh/uv/install.sh | sh

Install the project together with its development dependencies. To run the full suite (including the JAX implementations), include the jax extra:
```
uv sync --extra jax --group dev
```
To test the numpy-only installation instead, omit the extra:
```
uv sync --group dev
```

Now, the tests can be run. With the JAX extra installed, run the full suite except the numpy-only tests (which intentionally assert JAX is absent):

uv run pytest tests --ignore=tests/test_numpy_only.py --typeguard-packages=ikpls --cov=ikpls --cov-report=xml --cov-report=html

For a numpy-only installation, run only the numpy-only tests:

uv run pytest tests/test_numpy_only.py --cov=ikpls --cov-report=xml --cov-report=html

Lint

The package is linted with ruff in CI. Reproduce the lint gate locally before pushing (this check must pass — it catches syntax errors, undefined names, etc.):

uvx ruff check ikpls/ --select=E9,F63,F7,F82 --output-format=full

CI additionally reports style statistics (line length, complexity), which do not fail the build:

uvx ruff check ikpls/ --select=E501,C901 --line-length=88 --exit-zero --statistics

Build the documentation

Install sphinx, the sphinx-rtd-theme, and the MyST-Parser:
```
pip3 install sphinx sphinx-rtd-theme myst-parser
```
Change to the docs directory:
```
cd docs
```
Build the documentation:
```
make html
```

Benchmarking

To run benchmarks, follow the instructions here.