Chemprop v2.3.1: a preactivation edge update, a discontinued v1, and a CPU-only image

The edge update uses preactivation, and the project says so

Chemprop cites six links across five reference entries at the top of its README, then records where the code departs from them. The inconsistency is the edge update function, which in every version of the package uses preactivation instead of postactivation initial edge hidden states. The Supporting Information of the version 2 paper is named as the place where the details live, which puts the explanation outside this repository rather than in the source or in the command line help. Two of the cited links cover the theory itself, one for molecules and one for reactions through learned representations of the condensed graph of reaction. Another covers multi-objective molecule generation with interpretable substructures, and another covers when quantum mechanical descriptors help graph neural networks. A version 1 paper and a version 2 paper from the same journal complete the set. Anyone benchmarking against those papers should check this line early, because the difference sits in the update rule rather than in the hyperparameters.

Version 1 is discontinued, and its documentation trail is still open

Chemprop v2 came out of a ground-up rewrite, and the README keeps a whole section aimed at people who have not moved yet. Support for v1 was discontinued once v2 shipped, yet the project still accepts v1 bug reports and tags them v1-wontfix so old issues stay findable. The published v1 documentation site is described as several versions behind the final v1 release, v1.7.1, and as not covering the full scope of features that shipped in v1. The advice given instead is to read the README on the v1.7.1 tag and then the v1 args.py file, which is where every command line argument v1 accepted is described. The transition guide is a published spreadsheet holding a side-by-side comparison of CLI options, a list of arguments planned for later v2 versions, and a list of changed default hyperparameters. Older material sits next to it, each pinned to a moment: benchmark scripts built against v1.6.1, an ACS Fall 2023 workshop with Colab exercises and a solution key, a Colab notebook written to run in Colab rather than as a local Jupyter session, a nanoHUB tool that needs no installation, and slide decks describing the project as of April 28th, 2020. A notebook named convert_v1_to_v2.ipynb in the examples directory covers the same migration from the inside.

Three dependency files sit in the tree and the image reads one of them

pyproject.toml is the modern declaration and it is long: lightning at or above 2.0, torch at or above 2.1, numpy, pandas, rdkit, scikit-learn, scipy, astartes with the molecules extra, ConfigArgParse, rich, descriptastorus, cuik_molmaker_pin, and myerson at or above 1.0.1. Optional extras hold the rest. The hpopt extra pulls ray with the tune extra, hyperopt, optuna, pydantic and a setuptools ceiling below 82, and the examples directory carries a matching notebook named hpopting.ipynb. The docs extra pins sphinx-argparse to any version but 0.5.0 and holds docutils below 0.21. The dev extra pins black to the 23 series and then adds autopep8, flake8, isort, bumpversion, pytest and pytest-cov, so three formatting or import tools and a linter share one extra group. The top-level tree also carries a requirements directory and an environment.yml, which means more than one place can hold a version. What the Dockerfile does not do is read any of it. It copies the source into /opt/chemprop, points PYTHONPATH there, runs conda env update against the root environment.yml inside an environment named chemprop_env, clears the conda cache, and installs the project with python -m pip install --no-deps. Every runtime dependency has to arrive through conda before pip runs, so a version added only to pyproject.toml is invisible to the image.

Python 3.11 to 3.14, and the image pinned to one 3.12 build

The package requires Python 3.11 or newer and stops before 3.15, with classifiers for 3.11, 3.12, 3.13 and 3.14. The published image picks a single point inside that range by creating conda environment chemprop_env with python=3.12*, so someone on 3.11 and someone on 3.13 are both outside what the image represents. At the operating system level it installs one package, libxrender1, through apt-get and then removes it again with autoremove, because RDKit needs it. No CUDA runtime appears anywhere in the file. The build recipe is a comment block at the top of the Dockerfile:

git clone https://github.com/chemprop/chemprop.git
cd chemprop
docker build --tag=chemprop:latest .

Before that comment block, the file also switches the build shell to conda run with --no-capture-output inside chemprop_env, which is how commands run inside a conda environment when conda init and a shell restart are not available during a build.

The container entrypoint is a login shell, not a chemprop command

The image is assembled to hand over a shell rather than to run a program. conda init runs, the line conda activate chemprop_env is appended to the root user bashrc, and the entrypoint becomes /bin/bash --login. Starting it looks like this:

docker run --name chemprop_container -it chemprop:latest

Two things follow from that shape. There is no default command, so an invocation without -it gets a container that exits when its shell ends, and any automated run has to pass the training or prediction entry point explicitly. And because activation lives in a bashrc file rather than in the entrypoint itself, a process that does not read that file will not find chemprop_env on the path, leaving only the PYTHONPATH pointing at /opt/chemprop. There is no USER instruction in the file either, so the build and the shell both run as root inside the container.

Interpretation arrives as notebooks while myerson is a required install

The README describes the interpretation functionality as available in v2 as an example notebook, based on a paper about multi-objective molecule generation with interpretable substructures. The examples directory holds 24 notebooks, and the ones tied to interpretation and to atom and bond prediction are named after what they do: interpreting_with_myerson_values.ipynb, interpreting_monte_carlo_tree_search.ipynb, shapley_value_with_customized_featurizers.ipynb, mol_atom_bond.ipynb and constrained_mol_atom_bond.ipynb. In the same dependency list, myerson at or above 1.0.1 is a plain runtime requirement rather than an extra, so every install pulls it whether or not Shapley values or tree search are ever used, while the code that would use it stays in notebooks. Atom and bond prediction, which the reference list attaches to a paper on when quantum mechanical descriptors help graph neural networks, is reachable the same way. The rest of the directory follows the pattern: active_learning.ipynb, uncertainty.ipynb, transfer_learning.ipynb, multi_task.ipynb, mpnn_fingerprints.ipynb, rigr_featurizer.ipynb, chemeleon_foundation_finetuning.ipynb and use_featurizer_with_other_libraries.ipynb. Capabilities that show up in published applications arrive as notebooks to read and adapt rather than as imports to call.

The newest release tag has a v prefix and the two before it do not

The three most recent releases are not named the same way. The newest is v2.3.1, tagged on 2026-08-04. Before it sit 2.3.0 from 2026-07-08 and 2.2.4 from 2026-07-01, both written without the leading v. Anything that matches tags by name has to tolerate both forms within one major line. Inside the project the version string in pyproject.toml reads 2.3.1, which agrees with the current tag, and a .bumpversion.cfg file at the repository root is what drives that number. Two more root files are pure bookkeeping: CITATIONS.bib holds the references and third_party.txt holds third party notices. The default branch is main, the last recorded push is 2026-09-01, and the repository is not archived.

MIT in the files, no asserted license value on the index

The license terms are unambiguous inside the repository and thin outside it. The README states that Chemprop is free to use under the MIT License with LICENSE.txt at the root, and that the logo is free to use under CC0 1.0 under its own file in the logo directory. pyproject.toml says MIT twice, once as license text and once as a trove classifier, and its author field points at the same LICENSE.txt with the address [email protected]. The license value carried for this repository on the package index reads NOASSERTION, which is a marker for no assertion rather than a license, so a tool that gates on that field alone sees no terms at all and can stop a redistribution that the files themselves allow. Read LICENSE.txt and the logo file rather than trusting the index value. One more gap sits in what the package metadata shows: the pyproject file stops partway through the project URLs table, at the pypi entry, so the remaining project URLs cannot be read from it.

Editorial conclusion

Chemprop fits researchers who want message passing models and already carry the PyTorch and RDKit stack, and the published work on antibiotics shows it has been used past the notebook stage. Three things deserve a check first. The edge update in every version uses preactivation, which is not the formulation in the cited papers, so published numbers may not reproduce exactly. Version 1 support is discontinued, so anything depending on v1 behavior is frozen. And the only self-contained install recipe in the tree is a CPU-only image, while install detail lives on the documentation site instead of the README. Read LICENSE.txt rather than the index license value, and keep your Python inside 3.11 to 3.14 before pinning anything.

Frequently asked questions

Official sources

1. chemprop/chemprop on GitHub
2. Issues
3. Project website
4. README
5. Releases