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 severalways to contribute, including:

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:

  1. 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.

  2. Install Python >=3.7 locally in order to run tests.

  3. pip installing 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
    
  4. 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
    
  5. Create a branch where you will develop from:

    git checkout -b name-of-change
    

    And implement your changes.

  6. 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
    
  7. 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
    
  8. 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.