PyKale's six verbs and one composer decide what fits the library

Six verbs and a composer, and the order is the interface

The whole API is a fixed sequence. `loaddata` loads data from disk or online resources, `prepdata` preprocesses it into a form the modules below can accept, `embed` maps the data into a new space to learn a representation through feature extraction or selection, `predict` produces an output, `evaluate` scores it against metrics, and `interpret` reads the features and outputs back through post-prediction analysis, mainly visualization. A seventh module, `pipeline`, is the one that composes the others into a workflow. The order is not a convenience, it is the product, and the stated reason is a design rule the project calls green machine learning: reduce repetitions and redundancy, reuse existing resources, and recycle learning models across areas. Read that way, the vocabulary is a compression scheme for research code rather than a set of helpers. Note where `interpret` sits, after `evaluate` and last of the six, which makes the sequence a record of a whole experiment rather than a training script. The cost of a fixed vocabulary is the usual one: a task that does not decompose into those six gets bent until it does. The audience is stated as both sides of the trade, machine learning experts and end users, and the claim made for the design is that it is accessible, scalable and sustainable. Whether a six-verb interface is genuinely simpler for a non-expert is the question the examples directory answers better than the prose does.

One of four in the landscape, and the only one aimed at training

The positioning claim in the README is specific and checkable. PyKale is described as one of only four libraries officially listed under Multimodal in the PyTorch Landscape, alongside MMF from Meta, NeMo from NVIDIA and USB from Microsoft, and as the only one of those four positioned for training rather than modeling, with the focus on reusable workflows, evaluation, adaptation and deployable multimodal systems. Underneath that it does multimodal learning and transfer learning for graphs, images and video, with supporting models on deep learning and dimensionality reduction, aimed at bioinformatics, graph analysis, image and video recognition and medical imaging. The stated theme is leveraging knowledge from multiple sources for accurate and interpretable prediction. Around the code there is a project homepage, documentation built elsewhere, an arXiv preprint, and four short videos whose titles say what they are: why build PyKale, how it was built, what is in it, and a five-minute summary. There is also a workshop page for an Open Biomedical Multimodal AI Research Workshop at EMBC-2025, backed by a separate tutorial repository. The endorsement at the top of the README comes from Kevin Carlberg, an AI research science manager at Facebook Reality Labs, who calls it a library with a lot of good ideas about moving toward green, efficient multimodal machine learning. Of everything in that header, the landscape claim is the one you can check against a list.

PyTorch has a ceiling, and pandas has one for a different reason

The dependency list in the packaging file is where this library's real constraints live, and every line carries a comment explaining itself. Core requirements are numpy at 2.0.0 or newer, pandas at 2.2.2 or older for compatibility with Colab and a specific Torch version, PyTorch Lightning at 2.3.2 or newer for the pipeline API only, scipy, scikit-learn, tensorly for the factorization and model weights APIs only, torchvision for the download, sampler and vision APIs, and torch at 2.6.0 or older. That last one is an upper bound rather than a floor, so a machine with a newer PyTorch already installed has that decision taken away from it. The comment on the torch line also says to change the version in the test workflow file when the bound moves, and to update the PyTorch version inside a drug-binding tutorial notebook, so the pin lives in three places. Graph work adds networkx and a capped Therapeutics Data Commons package, and image work adds glob2, pydicom and pylibjpeg. The header of that file admits not every package states a minimum version, and it names the PyTorch Geometric setup file as the reference it was modelled on. So the dependency list is also documentation, and it is the part of this repository most worth reading before you decide whether the ceilings are acceptable.

Build settings live in pyproject, dependencies live in setup.py

The project uses both generations of Python packaging at once, and the split is not tidy. The pyproject file holds the build system, requiring a single pinned setuptools version, wheel and numpy through the setuptools backend, and it holds all of the tool configuration: black with a line length of 120 targeting Python 3.11, isort using the black profile with the same width, the local packages docs, examples, kale and tests marked as first party and five third-party names declared, and pytest configured to log to the console at INFO with a format string carrying a timestamp, a padded level name, the message, the file name and the line number, and a separate date format written out as year, month, day, hours, minutes and seconds. Two isort switches are written as quoted strings rather than booleans, which is harmless and looks like a leftover. The dependency list, the extras for graphs and images, and the explanation for each package all sit in the older setup.py instead, with a note that changing an option name means updating the installation guide page and the requirements file under docs. The repository root also carries a setup.cfg, a pre-commit config, a readthedocs config, a tests directory and an AGENTS.md.

Domain adaptation is the largest family in the examples directory

Sixteen example directories sit next to the package, each holding a real application on a specific dataset with the same internal structure, and they are where the library's actual centre of gravity shows. The adaptation family is the biggest: action recognition adaptation, an office multi-source adaptation task, a toy domain adaptation task, and multisite neuroimaging adaptation. Medical imaging follows with cardiac MRI and landmark uncertainty, then pharmacology and drug discovery with two binding database tasks and a polypharmacy graph task, then multi-omics, a few-shot protonet example, a multimodal digit task, an action video multimodal task, a video loading example, and the small vision baselines for digits and CIFAR including a CNN and transformer pair. Each is described as runnable with a variety of settings, with or without PyTorch Lightning, which is a useful thing to know before you copy one. The breadth is real, and the depth is one example per task rather than a benchmark suite, so the directory reads as a coverage map of transfer learning problems, which is also how the library describes itself. All of them sit beside the package directory and a tests directory at the repository root, and each one is entered the same way, which is the practical argument for the fixed vocabulary: two different datasets, two different modalities, one shape of code.

One example opens in a browser, the rest need a clone

The documented path in is three steps, and only the first one is frictionless. Installation asks for Python 3.10, 3.11 or 3.12, tells you to install PyTorch first for your hardware, adds PyTorch Geometric if graphs are involved, and then reduces to a single line:

pip install pykale

Everything else is pointed at hosted documentation, including an installation guide with other options. The tutorial step links a short tutorial on using the API inside the examples, interactive notebook tutorials, and then, for the digit classification example specifically, a Colab notebook and a Binder launch, so that one example runs in a browser with no local setup. Workshop material lives in a separate tutorial repository that also backs the workshop page. The third step is aimed at people extending the library rather than using it, and refers to a tutorial on modifying an existing pipeline or building a new one. Questions go to the discussions tab, bugs to issues, and code by branch, fork and pull against a contributing guide kept in the .github folder, alongside a test workflow, a changelog and a pull request template. The README also links a coverage service and a wiki-style code browser, so the route from a question to the source is short even when the environment is not. So the first hour is easy and the second one is a local environment.

Version 0.2.0, with a 0.1.2 still titled as failed

The release history is three entries deep and unevenly spaced. Version 0.1.1 was published in August 2022, version 0.1.2 in July 2023, and version 0.2.0 in May 2026, so there is a three-year gap between the second and the third. The 0.1.2 entry is titled as a failed release that was to be deleted, and it is still on the releases page, which tells you the cleanup never happened. The changelog is a separate file under .github, linked from the header of the README as the changelog, rather than something generated from those tags, so the two histories have to be read together to know what changed. The library is not archived, its last push was on 2026-09-30, and it carries 488 stars, 73 forks and 20 open issues, which for a research library is a healthy amount of attention. What the spacing tells you is that the version number moves rarely, so pin the release you read against and expect the interface described in the documentation to lag the main branch by up to a release cycle. An AGENTS.md file at the root, next to a pre-commit configuration, says the project expects contributions prepared with tooling in mind, which is a small signal about how the remaining work gets done.

Interpret is the last verb, and it produces no model

One stage deserves separate attention because it is the one the library's own argument rests on. `interpret` reads features and outputs back after prediction, and the README describes it as post-prediction analysis carried out mainly through visualization, which makes it the only one of the six that returns understanding rather than an artefact. The stated goal of the whole project is accurate and interpretable prediction built on knowledge from several sources, and interpret is where that goal either happens or does not. There is an example named for landmark uncertainty, which is the one place in the directory where the interpretation step is the subject rather than an epilogue, and the chapter on pipelines is where a reader is pointed when they want to build something new. The uncomfortable consequence is that interpret is also the easiest stage to drop, because dropping it costs nothing at training time and shows up only when someone asks why the model answered what it answered. A project that uses the other five stages has kept the plumbing and lost the argument.

Editorial conclusion

PyKale is worth reading as a worked example of what a fixed vocabulary buys a research group, and worth using when your task really is load, prepare, embed, predict, evaluate and interpret. The gain is that two projects built on it look alike; the cost is that anything outside those six stages has to be bent to fit, and interpret is the stage most often bent away. Before you install, check two ceilings. PyTorch is pinned with an upper bound at 2.6.0, and pandas with one at 2.2.2 for Colab compatibility, so an environment with newer versions of either will be changed by the installer. Then check what you are getting: the release history is three versions deep, the newest is 0.2.0 from May 2026, a 0.1.2 marked as failed is still published, and only the digit classification example opens in a browser. Everything else means cloning the repository and building the environment yourself.

Frequently asked questions

Official sources

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