Contribution Guidelines
General Tips
Always make sure to use
assert
statements to compare the expected value with the actual value, rather than simply printing or logging the expected and actual values.Avoid using
print
statements for logging purposes. Use thelogging
module natively provided by Python approporiately with it’s various logging levels likeDEBUG
,INFO
,ERROR
, etc.You can create a config file by copying the test_config.ini.example to a
test_config.ini
file and making changes, for example, to the logging levels:
[test.settings]
DEFAULT_LOG_LEVEL: logging.ERROR
DEFAULT_LOG_LEVEL_TEXT: ERROR
Never hardcode any file paths. Always use import variables such as
INPUT_DIR
,OUTPUT_DIR
and useos.path.join()
to make file paths. This ensures that the tests will run independent of the OS they are running on.
Running Tests Locally
PyCharm, IntelliJ:
To run a single test:
Open to Run/Debug
+
to add testChoose Python “tests > unittests”
In dialog:
Target: Select Script path, browse to test script
Choose Python interpreter
Click ‘OK’ to save
Run or debug the test from the configurations menu
To run all tests:
Open to Run/Debug
+
to add testChoose “Python tests > unittests”
Release to PyPI
A Github action is set up to automatically release the package to PyPI. When it is ready for a new release, create a Github release. The version should be in the vX.X.X format following the semantic versioning specification.
Release notes should always be autogenerated (just click the “generate release notes” button) - these can be tweaked but the emphasis should be on making sure PR titles and githu issue titles are clear and concise. Note we don’t keep a separate CHANGELOG file, it all goes in the release notes.
After the release is created, the GitHub action will be triggered to publish to PyPI. The release version will be used to create the PyPI package.
If the PyPI release failed, make fixes, delete the GitHub release, and recreate a release with the same version again.