TeachOpenCADD: computer-aided drug design taught through runnable notebooks

A gap in cheminformatics documentation, and a student-built answer

TeachOpenCADD is a teaching platform for computer-aided drug design, CADD, using open source packages and data, and the README is direct about the problem it addresses.

Open source programming packages for cheminformatics and structural bioinformatics are powerful tools to build modular, reproducible and reusable pipelines for CADD. While documentation for such tools is available, only few freely accessible examples teach the underlying concepts focused on CADD applications, and it addresses especially users new to the field.

That is a real gap. The teaching material is what fills that gap, and the framing of the project is unusually direct about it: a teaching platform developed by students for students.

The audience is stated with some care. Since the platform covers both the theoretical and the practical aspect of these topics, it addresses students and researchers with a biological or chemical as well as a computational background. That is a deliberate audience, and it explains a lot about the design choices below.

The primary language of the repository is Jupyter Notebook, the licence is CC-BY-4.0, and the homepage is projects.volkamerlab.org/teachopencadd. The repository is not archived, and the last push was on 2026-09-01. The release history shows 2026.04.1 in April 2026, 2026.04.0 a week earlier, and then a long gap back to 2023.05.2 in June 2023, which is the version scheme of a project versioned by year and month of its teaching material edition.

There is a peer-reviewed publication behind it. The topics figure is adapted from Figure 1 in the TeachOpenCADD publication by Sydow and others in J. Cheminformatics in 2019, and the README asks that you cite the platform if you use it in a publication, and link back to the repository if you use it in class.

The talktorial catalogue, and what the numbering tells you

The README's table of talktorials is the syllabus, and reading it shows how the field is taught.

The early group is compound-centric. T001 is compound data acquisition from ChEMBL, T002 is molecular filtering with ADME and lead-likeness criteria, T003 is molecular filtering for unwanted substructures, T004 is ligand-based screening by compound similarity, T005 is compound clustering, T006 is maximum common substructure, and T009 is ligand-based pharmacophores.

Then protein structure. T008 is protein data acquisition from the Protein Data Bank, T010 is binding site similarity and off-target prediction, T014 is binding site detection, and T015 is protein ligand docking, with T016 covering protein-ligand interactions.

Then the data acquisition and pipeline topics: T011 on querying online API webservices, T012 on data acquisition from KLIFS, T013 on data acquisition from PubChem, and T018 on an automated pipeline for lead optimization.

Then simulation: T019 on molecular dynamics simulation and T020 on analyzing those simulations.

And then a block of machine learning. T007 is ligand-based screening with machine learning, T021 is one-hot encoding, T022 is ligand-based screening with neural networks, T033 is molecular representations, T034 is RNN-based molecular property prediction, T035 is GNN-based molecular property prediction, T036 is an introduction to E(3)-invariant graph neural networks, T037 is uncertainty estimation, and T038 is protein ligand interaction prediction.

Then a run of five on kinase similarity, T024 through T028, each from a different angle: sequence, kinase pocket with the KiSSim fingerprint, interaction fingerprints, and ligand profile, with T028 comparing the perspectives.

Two things are worth pointing out. The kinase block is four notebooks on the same target class approached four ways, which is a teaching device as much as a coverage plan: it shows that a similarity question has no single answer, and that the fingerprint you choose determines the answer you get. And the numbering has gaps, from T028 to T033, which reflects the fact that these are written and reviewed notebooks rather than a manufactured series.

The README notes a new edition: the platform has been extended with 6 notebooks introducing deep learning and its application to CADD related topics.

The runner, and why it is the piece worth copying

The infrastructure around the notebooks is more interesting than it first appears, and it is what makes the platform usable in a classroom.

You can run a talktorial in the cloud with no installation at all. The fastest way to explore is via Google Colab, and the instructions are to navigate to the Talktorials list in the Open in Google Colab section and click the notebook URL on the title column to launch the tutorial directly in the browser. There is also a read-only version of the materials for anyone who just wants to read them.

Locally, the README recommends the TeachOpenCADD runner, which takes care of downloading the talktorial and the necessary data and setting up a virtual environment for the talktorials. It is installed from PyPI:

pip install teachopencadd
teachopencadd -h

and a notebook is started by passing its talktorial ID:

teachopencadd 6  # change the ID to whichever talktorial you are interested in

There is a second route through uv, which the README points at as a way to run a notebook directly with no need to download the notebook by hand:

uv run --with teachopencadd teachopencadd -h

The design decision here is the one worth stealing. A teaching platform that asks each student to assemble a working scientific Python environment with rdkit, pypdb, biopandas, nglview and mdanalysis, then download the right data files, is a platform that loses half its students on setup. The runner removes that failure mode, and it does so with one command that takes a numeric ID.

The packaging reflects that. The project name is teachopencadd, the console script is teachopencadd = "teachopencadd.cli:main", and the build uses setuptools with setuptools_scm, with the version derived from the tag and written to teachopencadd/_version.py. The runtime dependencies are deliberately thin: requests, uv, rich, nbformat, nbval, pytest. The lab extra adds jupyterlab, black and nbconvert, and the docs dependency group carries the Sphinx stack including nbsphinx, sphinx-gallery, sphinx-material and pandoc. The presence of nbval and pytest in the runtime dependencies is the tell: the notebooks are executed as tests, not just served as documents.

The documentation build, and what the package excludes

The repository layout is compact and tells you what is and is not part of the distribution.

At the top level there is .github/, .gitignore, LICENSE, MANIFEST.in, README.md, devtools/, docs/, pyproject.toml, teachopencadd/ and uv.lock. The package data is restricted to the teachopencadd* package, and the exclusions are explicit: teachopencadd.talktorials*, docs*, tests* and devtools* are all excluded from the wheel.

That exclusion list is the interesting part. The talktorials themselves are not shipped in the package, which is why the runner has to download them, and it is why the runner exists at all. The notebooks are content, and content is versioned in the repository and fetched on demand, not baked into a wheel that would have to be re-released every time a notebook changed.

The docs directory carries a full Sphinx build, and the dependency group shows what it renders: sphinx-gallery for example galleries, nbsphinx to include notebooks in the documentation, sphinx-material for the theme, sphinx-copybutton for the copy buttons on code cells, sphinxext-opengraph for social previews, and pandoc for converting the notebooks. There is a badge for a test talktorials workflow, and a README link to an external dependencies page that lists the full set of open source packages the notebooks use.

The Zenodo badge in the README, pointing at DOI 10.5281/zenodo.1486226, is the piece that makes this a teaching resource rather than a pile of notebooks. It gives the material a citable archive, which is what a lecturer needs in order to put it on a reading list and what a student needs in order to reference it. The CC-BY-4.0 licence is the other half of that, since a Creative Commons licence with attribution is what makes a notebook reusable in a course, a thesis and a paper without renegotiating terms each time.

The lab extra is worth noticing too. jupyterlab, black and nbconvert are what you need to actually work with the material rather than just read it, and they are an optional extra rather than part of the base install, which keeps the base package small for the read-only and Colab paths.

Where TeachOpenCADD is the wrong choice

There are three limits, and the first is about what a notebook is and is not.

The first is that this is teaching material, not a pipeline. The README says the material can serve as a starting point for users' project-directed modifications and extensions, and that is exactly the right way to think about it. A talktorial is a worked example with a narrative, an explanation of the concept, and a dataset that happens to be interesting. It is not a library with a stable API, it does not have error handling designed for unattended use, and it does not have the performance characteristics of something you would put in a production screening pipeline. The scripts inside a notebook are written to be read, and a script written to be read is often not a script written to be safe.

The second is the network dependency at runtime. The topics include querying online API webservices, data acquisition from ChEMBL, from the Protein Data Bank, from PubChem and from KLIFS, and a talktorial that runs in Colab must be able to reach those services. That is fine on a university network and on a laptop, and it breaks in an air-gapped teaching environment or behind a restrictive proxy. The runner handles the environment, and the README does not describe a mirror or an offline dataset snapshot.

The third is the maintenance coupling to the packages it teaches. The notebooks use rdkit, pypdb, biopandas, nglview and mdanalysis, and the dependency versions in those notebooks are not pinned by TeachOpenCADD's own pyproject.toml, which pins the runner's dependencies only. So a notebook that worked for the author when it was written can break when an upstream package changes behaviour, and the platform's response to that is the talktorials workflow badge and community contributions rather than a stated compatibility policy. For a course, that means the maintenance burden lands on whoever teaches it, which is a real cost that a version-locked service would not have.

There is also a licensing point specific to teaching. CC-BY-4.0 covers the material, which is the right choice for classroom reuse, and the README asks that you link back if you use it in class. But a course that adapts the notebooks, mixes them with your own material and distributes them to a paying cohort is a different act from linking back, and the attribution requirements deserve a look from whoever owns the course's IP.

Editorial conclusion

Adopt TeachOpenCADD if you are teaching or learning computational drug design and want worked examples that run against real open source tooling rather than pseudocode, especially if you need a reproducible environment for a class. Do not adopt it as a production CADD pipeline, since the material is built as teaching notebooks rather than a library, and note that the notebooks reach out to public databases and APIs at runtime. Verify first that the talktorials you care about still run against the current versions of the packages they use, that your students have the compute and network access those notebooks assume, and that the CC-BY-4.0 terms fit your teaching materials, since the platform is a set of licensed educational resources rather than a package with a permissive software licence.

Frequently asked questions

Official sources

1. License: CC-BY-4.0
2. Project website
3. README
4. Releases
5. volkamerlab/teachopencadd on GitHub