For developers¶
Adding new backends¶
See interface.py, which defines the interface of a backend and may serve as a template for creating new backends.
Setting up local GraphDB and Fuseki services for testing¶
Tripper comes with an inbuilt backend to the SPARQLWrapper. In order
to test this properly a real triplestore is needed. The automatic
workflows on GitHub run the tests against a Fuseki service, but not
against GraphDB. Local GraphDB and Fuseki services can be set up as
described below and tested with tests/backends/test_backends_sparql.py.
The backend configurations corresponding to the local GraphDB and Fuseki services can be found in tests/input/session.yaml.
Tests that need a service which is not running are skipped.
Starting GraphDB and Fuseki services¶
Start all services from the root of the repository with
docker compose -f test-services/compose.yaml up -d
or only some of them, e.g.
docker compose -f test-services/compose.yaml up -d fuseki
Add --wait to wait until the services are healthy. Stop them again with
docker compose -f test-services/compose.yaml down
▶ Manually start the services with docker
### Setting up GraphDB service To create the local instance of GraphDB:docker pull ontotext/graphdb:10.8.3 # latest tag 17.02.2025
docker run -d -p 7200:7200 --name graphdb ontotext/graphdb:10.8.3
curl -X POST -F "config=@tests/input/graphdb-test_repo-config.ttl" \
http://localhost:7200/rest/repositories
docker pull stain/jena-fuseki
docker run -d --name fuseki -p 3030:3030 -e ADMIN_PASSWORD=admin0 -e=FUSEKI_DATASET_1=test_repo stain/jena-fuseki
Tests that need a service which is not running are skipped.
Running tests in parallel¶
The tests can be run in parallel with pytest-xdist, which is included
in the testing extra:
pytest -n auto
Tests using the shared Fuseki and GraphDB "test_repo" datasets are marked
with @pytest.mark.xdist_group("triplestore"), which makes them run in
the same worker. For debugging (e.g. with --pdb or print()), run
without -n.
The first time the tests are run, tripper creates a cache with e.g. the units table generated from EMMO. To avoid that every worker creates it at the same time, you can create it before running the tests in parallel:
python tests/warm_cache.py
Running tests without internet access¶
Tests that need internet access are marked with network.
A faster, offline test run can be done with
pytest -m "not network"
Creating new release¶
Go to create a new GitHub release and create a new tag for the version, e.g. v1.0.8.
Use the tag as the release title (optionally write something else that defines this release as a title).
Optionally, write a release summary in the description.
The release notes, listing the pull requests merged since the previous release, are generated by GitHub and appended to the description by the release workflow.
You can also generate them yourself with the "Generate release notes" button, in which case the workflow leaves the description as is.
Pull requests with the skip_changelog label (e.g. dependency updates) are not included, see .github/release.yml.
Finally, press the "Publish release" button and ensure the release workflow succeeds.
The workflow sets the version of the package from the tag (the version in tripper/__init__.py is not updated in the repository), publishes it on PyPI and deploys the documentation for the release.
Testing documentation locally¶
To test the documentation locally, just install and run mkdocs:
pip install .[dev]
mkdocs build
mkdocs serve
Then open http://127.0.0.1:8000/tripper/ in your browser.
Profiling¶
To identify performance bottlenecks, install pytest-profiling and run run
pytest --profile
to generate a prof/ subdirectory with profiling information.
For a graphical overview, install gprof2dot and dot and run
pytest --profile-svg
This will create the figure prof/combined.svg, which shows what functions that uses most time and how many times they are called.
See https://pypi.org/project/pytest-profiling/ for more information.