DANCE: A Unified Python Package and Benchmark Platform for Single-Cell Deep Learning
DANCE: a deep learning library and benchmark platform for single-cell analysis
At a glance
- What is it?
- DANCE 1.0 bundles popular deep learning methods for single-cell analysis behind a shared data, training and evaluation interface, so that published experiments can be reproduced from a script and a few CLI flags. DANCE 2.0 is announced as a preprocessing recommendation platform, but its code, web platform and API are still listed as unstarted.
- Who is it for?
- Adopt DANCE if you need to reproduce a specific published single-cell benchmark and want the dataset download, graph construction, training and evaluation handled by one Python package under BSD-2-Clause. Do not adopt it yet if what you actually want is DANCE 2.0's preprocessing recommendation: the README lists the codebase, web platform and API as unreleased.
- Can I use it commercially?
- Yes. BSD-2-Clause is a permissive licence: you can use, modify and sell software built on it, as long as you keep its copyright and licence notices.
- Is it still maintained?
- Yes. The repository last received commits 4 days ago.
- What is it written in?
- Mainly Python, according to GitHub's language statistics.
Answers come from the project's GitHub data, last synced on September 15, 2026, and from our analysis. They are not legal advice.
DEEP OPEN-SOURCE ANALYSIS
The reproduction problem DANCE was built to answer
Single-cell deep learning papers are hard to compare because each one prepares its data and scores its results its own way. The README states the problem directly: different studies prepare datasets and perform evaluation differently, and methods are often written in different languages or pinned to incompatible library versions. DANCE's answer is to implement a set of popular computational single-cell methods inside one Python package and give them shared tooling for data downloading, preprocessing and transformation (graph construction is named as an example), and model training and evaluation. The intended user is a computational biologist or ML engineer who wants to rerun a published experiment rather than write a new pipeline from scratch. The README describes release 1.0's main usage as providing readily available experiment reproduction, with the reproducible experiments living under examples/. That is a narrower promise than a general-purpose analysis framework, and it is worth reading it that way.
Three analysis modules and where the method coverage stops
The package is organised around three modules. Single-modality analysis covers cell type annotation, clustering and gene imputation. Single-cell multimodal omics covers modality prediction and modality matching, but the README marks both as available only in DANCE 1.0, plus joint embedding. Spatially resolved transcriptomics covers spatial domain identification and cell type deconvolution. The parenthetical notes matter: if you are working on multimodal omics and expect the 2.0 line to carry those tasks forward, the README does not say that it does. The topics list on the repository mentions graph neural networks and spatial transcriptomics, which is consistent with the module layout, but the README itself does not map individual algorithms to individual modules beyond the example it gives. For method-level coverage you have to read the examples directory, not the overview.
How a benchmark run is assembled: script, dataset IDs, CLI flags
The README walks through cell type annotation with scDeepSort. After installing DANCE, you navigate to examples/single_modality/cell_type_annotation and run the script with flags that select the species, tissue, and the numeric dataset identifiers for training and testing. The documented command for the Mouse Brain experiment is:
python scdeepsort.py --species mouse --tissue Brain --train_dataset 753 3285 --test_dataset 2695
The README tells you to obtain the CLI options for a given experiment at the end of the script itself, which implies each example declares its own argument parser rather than sharing one global interface. The numeric IDs are the mechanism that ties a run to a specific dataset, and the data download step is handled by the package rather than by you. This is the data flow: flags select datasets, the package fetches and preprocesses them (including graph construction where the method needs it), the model trains, and evaluation runs under the shared harness. The README's example section is truncated mid-sentence at "Step3. Wait for the experi", so the expected runtime, output format and result location are not documented in the material available here. Check the script and the docs site for those before planning a run.
DANCE 2.0 is a plan, not a dependency
The README presents DANCE 2.0 as an automated preprocessing recommendation platform intended to replace trial-and-error preprocessing with a systematic, data-driven and interpretable workflow. It also publishes an unchecked release schedule: open-source release of the 2.0 codebase, launch of a web platform for uploading datasets and receiving preprocessing recommendations, and release of an API for programmatic access to those recommendations. None of the three boxes is ticked in the README. There is a bioRxiv preprint cited for 2.0, so the method is described in the literature, but the repository material does not show the corresponding code. If your evaluation depends on the recommendation feature, you are evaluating a paper, not a package. The 1.0 line is what exists as installable software here, and the newest tagged release is v1.0.1 from December 2023.
Installation, packaging and the release cadence you inherit
DANCE ships on PyPI as pydance, and the README's installation section is referenced rather than reproduced in the excerpt available here, so the exact pip invocation is not something this article can state. The documentation lives at pydance.readthedocs.io. The release history is short and front-loaded: v1.0.0rc0 in August 2022, v1.0.0 in June 2023, and v1.0.1 in December 2023, described as bug fixes and new datasets. The repository's last push is dated September 2026, which is later than the newest release, so there is activity on main that has not been tagged. That combination, a small number of releases and untagged activity, means you should decide whether to pin to the v1.0.1 tag or track main, and the README does not tell you which is intended for users. The CONTRIBUTING file is described as covering automated quality controls and dev environment setup, which is the place to look if you intend to run the test examples workflow yourself.
Licence and what it does not settle
DANCE is BSD-2-Clause, a permissive licence that allows use, modification and redistribution with the copyright notice and disclaimer retained. For a research group or a company embedding the package in an internal pipeline, that is about as unobstructed as licences get, and it is a meaningful difference from copyleft options in this space. What the licence does not cover is the data. The package downloads datasets on your behalf, and the terms attached to those datasets come from their original sources, not from DANCE. The README's citation section asks users to cite the DANCE package or the survey paper, which is a request, not a licence condition. This is not legal advice; if you are shipping a product that depends on a specific dataset's redistribution terms, read that dataset's own licence.
Where DANCE is the wrong tool, and what to use instead
DANCE is a reproduction harness. If your goal is to analyse your own dataset end to end with a single method and you do not care about matching a published benchmark, the shared preprocessing and evaluation machinery is overhead, and the example-script structure means you will be adapting someone else's experiment rather than composing your own pipeline. The alternative in that case is Scanpy, which is a general single-cell analysis toolkit built around the AnnData object and a broad, composable set of preprocessing, clustering and visualisation functions. The difference in approach is the axis of design: Scanpy gives you primitives you chain together for an analysis, while DANCE gives you whole experiments, each with its own script, dataset IDs and evaluation, chosen so that a published result can be rerun. If your work is method development and you need to compare against several baselines on the same splits, DANCE's unified data and evaluation layer is the reason to pick it. If your work is exploratory analysis of one new dataset, Scanpy's composability is the reason to pick that instead. The two are not substitutes for the same job.
Who should adopt it, and what to check first
Adopt DANCE when you need to reproduce a specific benchmark that the examples directory already covers, and you want the dataset download, graph construction, training and evaluation handled by one package under a permissive licence. Do not adopt it when your actual requirement is DANCE 2.0's preprocessing recommendation, because the README lists the codebase, web platform and API as unreleased, and the newest tagged release in the material is v1.0.1 from December 2023. Before you commit, do three concrete things. Open the example script for your task, for instance examples/single_modality/cell_type_annotation/scdeepsort.py, and read the CLI options at its end to confirm your target experiment is covered. Check whether the numeric dataset IDs you need appear in that script, since the IDs are how a run is bound to data. And decide between pinning pydance to v1.0.1 and tracking main, given that the repository's last push postdates the newest release and the README does not state a policy either way.
Editorial conclusion
Adopt DANCE if you need to reproduce a specific published single-cell benchmark and want the dataset download, graph construction, training and evaluation handled by one Python package under BSD-2-Clause. Do not adopt it yet if what you actually want is DANCE 2.0's preprocessing recommendation: the README lists the codebase, web platform and API as unreleased. Before committing, open the example script for your task under examples/ and read the CLI options printed at its end, then check the last release date against your dependency pins, because v1.0.1 is the newest tagged release and the repository's last push is later than it.
Community notes