PyKale: a pipeline API for multimodal and transfer learning on graphs, images and video

The gap PyKale targets is between data sources, not between model architectures

Most PyTorch libraries hand you layers or pretrained weights and leave the wiring to you. PyKale's stated aim is different: it exists to make machine learning accessible to interdisciplinary research by bridging gaps between data, software and end users. The phrase that matters in that sentence is interdisciplinary. The intended user is a researcher in bioinformatics, graph analysis, image or video recognition, or medical imaging who has data from more than one source and needs a defensible training and evaluation procedure, not someone hunting for a new attention block. The README frames the goal as knowledge-aware learning from multiple sources, with interpretability named as part of the prediction target rather than an afterthought. That framing explains why the library ships examples keyed to specific datasets instead of a catalogue of architectures. It also explains the audience boundary. If your problem is one dataset, one modality and one train/test split, PyKale's abstractions cost you more than they return.

Seven named stages turn a training script into a pipeline

The API is a fixed vocabulary of stages. loaddata reads from disk or online resources. prepdata applies transforms so the data fits the modules below it. embed projects data into a new space to learn a representation, covering feature extraction and selection. predict produces the output. evaluate scores it with metrics. interpret runs post-prediction analysis, described as mainly visualization. pipeline composes the other stages into a workflow. That is the whole architecture as documented, and it is deliberately shallow. The value is not in any single stage but in the naming contract: once a team agrees that feature selection lives in embed and never in prepdata, two people can read the same example and know where to change it. The trade-off is that the vocabulary is opinionated. A workflow whose preprocessing and representation learning are entangled, which is common in end-to-end self-supervised setups, has to be split artificially across prepdata and embed or pushed into one stage and lose the labelling benefit.

Installation is two decisions before it is one command

The README is explicit that pip install pykale is not the first step. PyKale supports Python 3.10, 3.11 or 3.12, and the documentation states that you should first install PyTorch matching your hardware, and if graphs will be used, install PyTorch Geometric following its official instructions. Only then does the single install line apply. That ordering is not decoration. PyTorch wheels are hardware-specific and PyTorch Geometric has its own build requirements, so installing PyKale first and back-filling the framework tends to produce a broken environment. The repository layout reinforces the point: examples sit under a top-level examples directory with a standardized structure, and the README points to a digits_dann tutorial available both as a Colab notebook and through Binder. A sensible first contact is to open that notebook, run the digit classification example unchanged, and only then read its config to see which stage each block belongs to. The README also notes that examples vary in whether they use PyTorch Lightning, so the training loop you copy from one example is not necessarily the one you will find in the next.

Where PyKale stops being the right tool

The library's own scope statement is the clearest limitation. According to the README, PyKale focuses on multimodal learning and transfer learning for graphs, images and videos at the moment, with supporting models on deep learning and dimensionality reduction. That word supporting is doing real work. PyKale is not positioned as the place to find a state-of-the-art backbone; it is the place to find the workflow around one. If your task is tabular, time-series forecasting, or speech, the documented scope does not cover it, and you would be adopting the pipeline vocabulary without the examples that make it legible. There is a second, quieter failure mode. A pipeline API rewards teams that keep data loading, preprocessing and evaluation in separate files. If your data arrives as one monolithic array from an instrument and your evaluation is a single held-out fold, the seven stages become ceremony. The honest test is whether you have more than one source or more than one domain. If you do not, PyKale adds indirection for no gain.

MMF, NeMo and USB occupy the modelling slot PyKale deliberately vacates

The README states that PyKale is one of four libraries listed under Multimodal in the PyTorch Landscape, alongside MMF from Meta, NeMo from NVIDIA, and USB from Microsoft, and that it is the only one in that category positioned for training rather than modelling. That distinction is the useful comparison. MMF and NeMo are built around model families and pretrained checkpoints; you go to them when the architecture is the hard part. PyKale is built around reusable workflows, evaluation, adaptation and deployable systems, so you go to it when the hard part is that your images come from one scanner and your labels from another. The two approaches are not substitutes. A team that picks MMF for its model zoo still has to write the domain adaptation and evaluation code itself, and that code is precisely what PyKale's examples demonstrate. Conversely, a team that picks PyKale for its pipeline still has to bring or train its own backbone.

Version history and the cost of staying current

The release record is thin and worth reading before you plan an upgrade. Release 0.1.1 landed in August 2022, 0.1.2 in July 2023 and is labelled in the release list as failed and to be deleted, and 0.2.0 arrived in May 2026. The repository's last push is dated September 2026, so development has continued past that release. A gap of roughly three years between the 0.1.x line and 0.2.0 means any code you wrote against the older API should be treated as needing review rather than assumed compatible. The Python support window, 3.10 through 3.12, is another upgrade clock: when your environment moves past 3.12 you are dependent on the maintainers widening that range. For maintenance budgeting, the practical cost is not the library itself but the pinned ecosystem around it, since PyTorch and PyTorch Geometric versions move faster than PyKale releases. PyKale is MIT licensed, which is permissive and places few obligations on how you redistribute derived work, but licensing is not legal advice and you should confirm the terms against the LICENSE file in the repository and your own organisation's requirements.

Editorial conclusion

Adopt PyKale if your work is cross-domain or multimodal and you want a pre-shaped workflow with examples you can run before writing your own training loop. Do not adopt it if you have a single-modality pipeline already working, or if you cannot accept its folder and config conventions. Before committing, install PyTorch matching your hardware, install PyTorch Geometric if graphs are involved, then run one example end to end and read its config file to confirm the stage boundaries match how your data actually arrives.

Official sources

1. License: MIT
2. Project website
3. pykale/pykale on GitHub
4. README
5. Releases