Overviews for Developers
OpenPathSampling is an open-source project, and as such, we encourage contributions from other developers.
Of course, OPS is also a rather large code, and getting into it can be daunting. The documentation here is designed to help you identify what kinds of objects you should be creating to make the improvements you want to make, and to tell you what functions you must implement to make your additions work in OPS.
If you’re adding significant new functionality, we suggest a workflow where you keep your additions in a new and separate repository, rather than in your fork of OPS. This is because some functionality might not be applicable to enough cases for us to include it in the core code. If your package is outside OPS, it can still be distributed to those who are interested, even if it isn’t interoperable enough to go into the main repository.
Coding Style
Our coding style is mostly PEP8, with allowances for better readability and matching standard scientific naming conventions (e.g., capitalization of variable names). Docstrings are formatted according to the numpydoc standard.
Tests and Examples
Additions to OPS should include thorough tests. We use pytest to run our
tests, although we require nose for some legacy portions of the tests.
Unit/integration tests are located in the openpathsampling/tests/
directory. Examples and integration tests should be written as Jupyter
notebooks and placed in the examples/ directory. Pull requests to the
OPS GitHub repository will automatically run all unit tests with each push.
We also run a subset of the system tests on each push, using ipynbtest.
The sections linked below give details about extending OPS. The document on code structure gives an overview of the code, and the other documents describe specific aspects.