datamol: a light convenience layer over RDKit for molecular work

A defaults layer, not a replacement for RDKit

Datamol is a Python library to work with molecules, a layer built on top of RDKit that aims to be as light as possible, and the design commitment is stated plainly in the feature list: RDKit first, so all you manipulate are rdkit.Chem.Mol objects.

That single decision shapes everything else. Datamol does not introduce its own molecule type, so a Datamol result can be passed straight to any RDKit function, and a pipeline that mixes the two libraries does not need a conversion step. The trade is that you are still bound by RDKit's API and its version behaviour, which is exactly what the compatibility table at the end of the README is about.

The second feature is the one that makes the library worth having. Manipulating molecules often relies on many options, and Datamol provides good defaults by design. In practice this means the many arguments that some RDKit functions accept are not something you have to think about every time, because the library has already chosen sensible values and lets you override them.

The rest of the design is about the parts of cheminformatics work that are not chemistry. Performance matters, with built-in efficient parallelization when possible and an optional progress bar. And modern IO, with out-of-the-box support for remote paths using fsspec to read and write multiple formats including sdf, xlsx and csv. A concrete example from the API tour is reading a structure file straight from a data lake and writing the result to a cloud bucket, with no path handling in between.

There is a try-online route through Binder, which points at the tutorial notebook in the docs, so you can evaluate the API without installing anything. The documentation is at docs.datamol.io, the project homepage is datamol.io, and the package is on both PyPI and conda-forge, so it fits into a uv project, a pip environment or a conda environment without changes.

Installing it, and what 0.13 changed underneath

The recommended install for a uv-managed project is a single command:

uv add datamol

bash uv add datamol

Pip and conda-forge remain supported:

bash python -m pip install datamol mamba install -c conda-forge datamol ```

Datamol 0.13.0 requires Python 3.11 or newer and RDKit 2024.09 or newer. Cloud IO for S3 and Google Cloud, Excel and Parquet support, visualization and SELFIES support are all included by default, and there are no feature extras to install.

That last point is a change worth noticing. A library with a long history of optional extras for cloud backends and plotting is a common source of dependency conflicts in a scientific stack, and 0.13 separates the optional I/O and visualization dependencies from the core installation while still shipping them by default. The practical effect is that the install is one package and the set of transitive dependencies is larger than the core suggests.

The 0.13 release also modernizes the supported scientific Python stack while keeping the library focused on reliable molecular processing. It adds RDKit binary and property-dictionary interchange, enforces conformer RMS cutoffs with symmetry-aware alignment, fixes reported RDKit compatibility issues, and there is a migration guide alongside the complete changelog for the compatibility and transition details.

The version constraints are in the pyproject rather than left to the resolver. The build backend is setuptools with setuptools-scm for the version, and the tool.uv section requires uv 0.12.8 or newer. The runtime dependencies are the usual scientific stack, with tqdm, loguru, joblib, fsspec with the http extra, pandas, numpy, scipy, platformdirs, scikit-learn and packaging, and then rdkit at 2024.9.1 or newer. The I/O backends are gcsfs and s3fs with openpyxl and xlsxwriter and pyarrow, the visualization set is matplotlib, networkx, nglview and pillow, and SELFIES conversion adds its own dependency.

The licence is Apache-2.0 with the file listed under license-files, and the author is Hadrien Mary. There is a DOI on Zenodo and a request to cite the library if you use it in your research, which is the convention for a research-adjacent tool.

What the API tour shows, molecule to conformer to file

The quick tour in the README is short enough to read as a summary of the library's surface, and the sequence follows what a molecular pipeline actually does.

It starts with conversion. dm.to_mol takes a string and gives you an RDKit molecule, with a sanitize argument. From there the same molecule goes to a fingerprint with dm.to_fp, to a SELFIES string with dm.to_selfies, and to an InChI with dm.to_inchi. Those are the four representations a drug discovery pipeline usually needs, and the fact that they are four one-line calls is the pitch of the library in miniature.

Then the cleaning chain, which is where the defaults earn their keep. dm.fix_mol repairs a molecule, dm.sanitize_mol sanitizes it, and dm.standardize_mol standardizes it. Three separate calls rather than one, because each is a different kind of correction and mixing them changes what you get.

Then the data structures. dm.data.freesolv() returns a dataframe, and dm.from_df pulls the molecules out of it, which is the shape of most real work: a table with a structure column and some measurements.

Then the visual output, dm.viz.to_image with legends built from dm.to_smiles, and the 3D side, dm.viz.conformers with n_confs, which uses nglview. And the 3D numbers: dm.conformers.generate builds conformers, and dm.conformers.sasa computes the solvent accessible surface area from them, which is a physical property rather than a string transformation.

The last block is the IO, and it is the part that separates this from a pure RDKit wrapper, reading a structure file from a data lake path and writing the result to a cloud bucket.

The same functions that read a local file read a cloud path, and the as_df argument controls whether the result is a dataframe or a list. That is the fsspec layer doing its work, and it means a pipeline that runs in a notebook against a local file can be moved to a scheduled job against object storage without changing the reading code.

The API tour is also the best evidence that the library is thin in the right way. Every one of those calls is one or two lines against RDKit, so the abstraction costs you almost nothing in expressiveness.

The parts of a molecular pipeline the library actually touches

The API tour is worth reading as a workflow, because it reveals that a molecular pipeline has more stages than a SMILES string and a fingerprint, and datamol's contribution is spread across all of them.

The first stage is getting a molecule into a usable state. That is what to_mol with sanitize does, and it is also where a surprising number of real pipelines fail, because a SMILES string from a database is not always a valid molecule and the default behaviour of most toolkits is to warn rather than to raise. The three cleaning calls that follow, fix_mol, sanitize_mol and standardize_mol, are the same idea applied in stages.

The second stage is representation, and this is where the four conversion functions sit. A fingerprint is a vector for similarity search and machine learning, SELFIES is a string encoding that is valid by construction, which matters when the output has to be fed to a generative model, and InChI is the identity string that lets you look a molecule up in a database. The library gives you all four without making you learn four sets of RDKit arguments.

The third stage is geometry. dm.conformers.generate produces the three dimensional conformations of a molecule, which is a stochastic process, and dm.conformers.sasa computes the solvent accessible surface area from those conformations. The 0.13 release added symmetry-aware alignment and a conformer RMS cutoff for this step, which is the kind of detail that matters when you are comparing a generated conformation against a reference one and do not want the comparison to be thrown off by a symmetric molecule being aligned slightly differently each time.

The fourth stage is persistence, and this is where fsspec does the work.

The fifth stage is inspection. dm.viz.to_image renders a grid of molecules with legends, and dm.viz.conformers renders the 3D structures with nglview. Rendering is not a toy here, because in a medicinal chemistry review the picture of a scaffold is often how the decision is argued.

So the library is a convenience layer across conversion, cleaning, representation, geometry, persistence and inspection, and in each of those it is trying to do one thing: keep the number of decisions you have to make down to the ones that matter for your science.

The compatibility table, and why it is the part to read

The last substantive section of the README is the compatibility matrix, and the way it is framed is unusual enough to be worth quoting.

The framing is that version compatibilities are an essential topic for production software stacks, and that the project is cautious about documenting compatibility between datamol, python and rdkit. The table then lists, for each datamol minor version, the Python versions and the RDKit versions for which that minor version of Datamol has been tested during its whole lifecycle. And the caveat is explicit: it does not mean other combinations do not work, but that those are not tested.

That is a different contract from most packages, which imply that any recent combination works. Here the table is a statement about what has been exercised, and the current row is 0.13.x against Python 3.11 to 3.14 and RDKit 2024.09, 2025.03, 2025.09 and 2026.03. The 0.12.x row drops to Python 3.10 and 3.11 with RDKit 2023.03 and 2023.09, and the older rows walk back through the RDKit 2022 and 2021 series.

The CI configuration matches the table. The tests and code quality checks run on Linux x86-64, Windows x86-64, macOS on Apple Silicon and macOS on Intel, with Python 3.11 through 3.14 on Linux, the supported RDKit release series from 2024.09 through 2026.03, and the latest supported stack on every operating system and architecture lane. The main branch carries separate badges for the library build and testing and for code sanity, meaning formatting and linting.

The four platform lanes are worth a moment, because RDKit is a compiled library and the wheel availability differs per platform and per Python version. Running the full matrix on macOS Intel as well as Apple Silicon, and on Windows, is what makes the compatibility table trustworthy rather than aspirational.

The repository layout backs the same picture, with the package in datamol/, the tests in tests/, the documentation source in docs/ with an mkdocs.yml, a notebooks/ directory, a binder/ directory for the online environment, a pre-commit configuration, and an env.yml for the conda environment.

Editorial conclusion

datamol suits a team doing repetitive molecular work who finds that RDKit's option count and its IO layer are the parts they keep reimplementing, since datamol gives defaults, one-line format conversion and cloud paths without leaving RDKit objects. It does not suit you if you want a machine learning framework or a new cheminformatics capability, because everything it does is a thin convenience over RDKit and nothing more. Before you pin a version, read the compatibility table, because the project is explicit that it is cautious about documenting compatibility and only guarantees the combinations it has tested, and note that 0.13 dropped Python 3.10 and the older RDKit series.

Frequently asked questions

Official sources

1. datamol-io/datamol on GitHub
2. License: Apache-2.0
3. Project website
4. README
5. Releases