Contributing to NetKet#
Everyone can contribute to NetKet: it is only thanks to the involvement of a large community of developers that open-source software like NetKet can thrive. There are several ways to contribute, including:
Answering questions on NetKet’s discussions page
Improving or expanding NetKet’s documentation
Improving or expanding NetKet’s tutorial notebooks
Contributing to NetKet’s code-base
Ways to contribute#
We welcome pull requests, in particular for those issues marked with contributions welcome or good first issue. You can also have a look at our RoadMap for ideas on things that we would like to implement but haven’t done so yet. It is generally regarded good behaviour to let other know of your plan to contribute a feature.
For other proposals, we ask that you first open a GitHub Issue or Discussion to seek feedback on your planned contribution.
The NetKet project follows the Contributor Covenant Code of Conduct.
Contributing code using pull requests#
We do all of our development using git, so basic knowledge is assumed.
Follow these steps to contribute code:
Fork the NetKet repository by clicking the Fork button on the repository page. This creates a copy of the NetKet repository in your own account.
Install Python >=3.8 locally in order to run tests.
pipinstalling your fork from source with the development dependencies. This allows you to modify the code and immediately test it out:
git clone https://github.com/YOUR_USERNAME/netket cd netket pip install -e '.[dev]' # Installs NetKet from the current directory in editable mode. pre-commit install # Install the pre-commit hook that checks your commit for good formatting
Add the NetKet repo as an upstream remote, so you can use it to sync your changes.
git remote add upstream http://www.github.com/netket/netket
Create a branch where you will develop from:
git checkout -b name-of-change
And implement your changes.
Make sure the tests pass by running the following command from the top of the repository:
pytest -n auto test/
If your code contribution touches parts of NetKet that are expected to work under MPI, such the computation of expectation values, initialization of parameters or lazy matrix-vector products you should also check that tests pass under MPI by running pytest under MPI. When doing so, you should also disable pytest parallelization.
mpirun -np 2 pytest -n0 test/
NetKet’s test suite is quite large, so if you know the specific test file that covers your changes, you can limit the tests to that; for example:
pytest -n auto test/hilbert
Once you are satisfied with your change, create a commit as follows ( how to write a commit message):
git add file1.py file2.py ... git commit -m "Your commit message"
You can also use a graphical git client that simplifies a lot using Git. We suggest GitKraken or SourceTree.
Then sync your code with the main repo:
git fetch upstream git rebase upstream/master
Finally, push your commit on your development branch and create a remote branch in your fork that you can use to create a pull request from:
git push --set-upstream origin name-of-change
Create a pull request from the NetKet repository and send it for review. Check the NetKet pull request checklist for considerations when preparing your PR, and consult GitHub Help if you need more information on using pull requests.
NetKet pull request checklist#
As you prepare a NetKet pull request, here are a few things to keep in mind:
Single-change commits and pull requests#
It is considered good practice that every git commit sent for review is a self -contained, single change with a descriptive message. This helps with review and with identifying or reverting changes if issues are uncovered later on.
Pull requests ideally comprise a single git commit. (In some cases, for instance for large refactors or internal rewrites, they may contain several.) In preparing a pull request for review, you may want to squash together multiple commits.
We don’t really enforce or require those rules, but they are welcome additions.
Python coding style#
Code should follow PEP 8. For consistency, we use the Black code formatter. The precise version we use to check formatting will be installed when you install NetKet’s development dependencies as outlined above.
If you edit Python code, you should run Black on the affected files. On the command line, this can be done via
# to reformat a specific file black Path/To/The/file.py # to reformat all files below the specified directories black test/ Examples/
before creating a pull request. There are other options of running Black: For example, an Atom package is available and Black is integrated into the VS Code Python extension.
If you have installed pre-commit, black will be run automatically before you commit or if you run the command below.
pip install pre-commit pre-commit run --all
Docstrings and Type Hints#
If you have written new methods, we expect those to be documented with Type Hints for
their inputs and output using standard Python types from the
typing standard library
and NetKet’s custom types from
netket.utils.types for more advanced objects such
as PyTrees, Arrays and data types.
Your new methods and functions should always be documented with a docstring in the Napoleon Google’s format.
Visibility of public API#
If you have added an object that is supposed to be used by end-users and will be part
of the public API, we expect you to add this object to the documentation by adding
the relevant classes/functions to the auto-generated API in
docs/api.rst and eventually
by writing a new documentation page.
Full GitHub test suite#
Your PR will automatically be run through a full test suite on GitHub CI, which covers a range of Python versions, dependency versions, and configuration options. It’s normal for these tests to turn up failures that you didn’t catch locally; to fix the issues you can push new commits to your branch.