For bug fixes or new features, please file an issue before submitting a pull request. If the change is not trivial, it may be best to wait for feedback.
Tests are written as usual Python unit tests with the
unittest module of the
Python standard library. Running them can be done as follow:
$ python -m unittest discover -vv
As it is a good project management practice, we should follow semantic versioning, so remember the following:
As long as the model predicts the same thing, retraining/updating the model should be considered a non-breaking change, so you should bump the MINOR version of the program.
Upgrading the internal HMMs could potentially change the output but won’t break the program, they should be treated as non-breaking change, so you should bump the MINOR version of the program.
If the model changes prediction (e.g. predicted classes change), then you should bump the MAJOR version of the program as it it a breaking change.
Changes in the code should be treated following semver the usual way.
Changed in the CLI should be treated as changed in the API (e.g. a new CLI option or a new command bumps the MINOR version, removal of an option bumps the MAJOR version).
Upgrading the internal HMMs¶
To bump the version of the internal HMMs (for instance, to switch to a newer
version of Pfam), simply edit the INI file for that HMM in the
Then clean and rebuild data files to download the latest version of the HMMs:
$ python setup.py clean build_data --inplace
Upgrading the internal CRF model¶
After having trained a new version of the model, run the following command to update the internal GECCO model as well as the hash signature file:
$ python setup.py update_model --model <path_to_new_crf.model>