7.3. Ontolopy tools and practices

This section briefly describes the tools and practices that Ontolopy is built upon.

7.3.1. Practices

Development philosophy:

Continuous Integration

Continuous integration, delivery, and deployment enable running tests and updating packaging frequently by automatically doing these things when changes are made to a version-controlled repository[123].

Ontolopy aspires to Research Software Engineering best practice, including:

• Automated testing with pytest which are continuously integrated with GitHub Actions.

• Semantic Versioning to make the package versions informative and useful for others.

• Thorough documentation, which is versioned. This means that you can always reach the documentation corresponding to the version of the software you are using - you can access this at /versions/{tagged_version}, e.g. v1.0.2-beta is here.) The documentation is also built automatically using GitHub Actions.

• Keeping a small number of dependencies, which are: numpy[228] and pandas[229] for general data manipulation, and validators (for validating URLs)

Open Source:

Ontolopy is Open Source (with an MIT license), and available on GitHub. This means that:

• anyone can contribute to it. I provided developer guidance and “good first issues” to reduce the barrier to this.

• anyone can download, use, reuse, or adapt the source code for their own work. This is made easier by the fact that Ontolopy is distributed via the Python Package Index.

Style:

Ontolopy uses consistent programming style and conventions to make it easier for others to work with (these were adapted from the MetaWards package developer guide[230]:

• Python-style naming conventions:

  • Packages: lowercase (single word)

  • Classes: CamelCase

  • Methods, Functions, Variables: snake_case

• Functions with leading underscores (e.g. _extract_source()) are meant for internal use only.

• Relative imports should be used at all times, with imports ideally delayed until they are needed.

7.3.2. Tools

Packaging:

Packaging is carried out automatically using GitHub actions whenever a new version of the software is “tagged” via GitHub. This uses the twine[231] Python Package.

Testing:

Tests are automatically run whenever Ontolopy code is changed on either the GitHub main or dev (development) branches. This is achieved with GitHub Actions and the pytest[232] Python Package.

Logging:

Python’s in-built logging module is used to integrate logging messages from dependencies as well as adding useful logging messages for Ontolopy users. This allows informative messages to be printed to the console or to a log file.

Documentation:

Ontolopy’s documentation is hosted on GitHub pages here, and built using Sphinx with the pydata-sphinx-theme theme[233], and it is automatically built using GitHub Actions whenever there are changes to the development branch or when there is a new release. It also makes use of following tools:

• peaceiris’s GitHub pages action - to automatically update a GitHub pages site in a GitHub Action.

• sphinx.ext.autosummary - to automatically build an API Reference from docstrings in code.

In addition to the above tools which were built by others, I wrote a small local sphinx extension to create the versioned documentation. This, in turn, uses gitpython and pygithub.