small-text: three pluggable pieces on a version still marked alpha

The trove classifier says Production/Stable while the README says alpha

The packaging metadata and the project page disagree about how finished this is. The classifier list in the manifest carries Development Status :: 5 - Production/Stable, the highest of the five levels, and the same block declares Python 3.10, 3.11 and 3.12 support under an OS Independent heading.

The README describes the current release as a development release with the most changes so far, which you can consider an alpha release, which does not guarantee you stable interfaces yet, but is otherwise ready to use.

Neither statement is false on its own terms. A classifier describes the package as a whole and 1.4.1 was a production line, while the alpha note describes what 2.0.0.dev4 will change. The problem is that both are true at once, so neither is a usable answer to whether your code will keep working.

The mechanism that makes it stick is that the version is a development version rather than a release. Nothing in the manifest separates a stable 1.x from a 2.x pre-release except the version string itself and the MIGRATION_GUIDE.md at the repository root, which exists to tell you what moved.

The transformers extra cannot be installed without torch

There are two extras and one of them is recursive. The pytorch extra is torch at 2.0.0 or newer. The transformers extra is not just transformers at 4.57.6 or newer, it is also a requirement on small-text with the pytorch extra.

So pip install small-text[transformers] pulls torch whether or not you have a GPU. That is not written as a warning anywhere in the README, which presents the extra purely as the full install variant.

The two commands it does document are these:

pip install small-text

pip install small-text[transformers]

The consequence is that the two advertised install shapes are not really two shapes. Either you take the slim install with the eight base dependencies and no transformer models, or you take a stack that includes torch, and torch is a large dependency to acquire for a text classification experiment running on a CPU.

The base dependency list is what the slim install amounts to: dill, scipy, numpy at 1.21.0 or newer, scikit-learn at 0.24.1 or newer, tqdm, packaging, tokenizers at 0.22.0 or newer and tomli. Nothing in that list needs a GPU.

Three dev releases, no 2.0.0, and the documentation is pinned to dev4

The release list is three deep and none of them is 2.0.0. v2.0.0.dev2 came in May 2025, v2.0.0.dev3 in August 2025, and v2.0.0.dev4 on 2026-05-23. The gap between dev3 and dev4 is nine months, and the gap between dev4 and now, with the last recorded push on 2026-09-28, is four months with no new tag.

The documentation is versioned to dev4 rather than to a moving latest. The badge and every notebook link point at the readthedocs build for v2.0.0.dev4 and at GitHub paths that include the v2.0.0.dev4 tag, so the tutorial you follow is pinned to the same pre-release the manifest declares.

That pinning is a deliberate choice and it has a cost. It means the documentation cannot drift away from the release, but it also means the docs stop describing whatever has landed on main since May.

The stable line is older still. Version 1.4.1, dated 18 August 2024, is described in one line as a bugfix release, and it is the last entry in the news section that is not about version 2.

dill and tokenizers are what the slim install actually is

Two entries in the base dependency list tell you what this library is doing that a plain scikit-learn pipeline would not do.

dill is a serialisation library that pickles by value rather than by reference, which is what lets an active learning run be written to disk and reloaded later with its query strategy state intact. A run that has already spent annotation budget is expensive to reproduce, so being able to save and resume it is the feature the rest of the design serves.

tokenizers at 0.22.0 or newer is the Hugging Face tokenizer library, present even in the slim install. That is the piece that lets the same pipeline sit over a scikit-learn classifier and over a transformers model, because both need the same tokenisation and normalisation step.

The remaining six are ordinary. scipy and numpy for the numerics, scikit-learn for the classifiers, tqdm for progress on long loops, packaging for version comparison, and tomli for reading configuration files on older Python versions.

Nothing here pulls a deep learning framework by default, which is the concrete meaning behind the claim that a CPU only install is lightweight.

Three pluggable pieces, and the classifiers are interchangeable

The library's stated contribution is a set of scientifically evaluated components that are pre-implemented and ready to use, named as query strategies, initialization strategies and stopping criteria.

The division of labour follows the shape of an active learning run. A query strategy decides which unlabelled example to send to the annotator next. An initialization strategy decides what to do before any querying starts. A stopping criterion decides when to stop, which is the piece that stops a run from spending the whole budget.

On top of that sit unified interfaces, so query strategies can be mixed and matched with classifiers supplied by scikit-learn, PyTorch or transformers. The classifier is a swappable part rather than a choice you commit to, and the transformers integration is what lets you use current text classification models rather than classical features.

What this buys you is a run you can describe rather than assemble. The claim is not that any single strategy is better, it is that the pieces are already evaluated and already interoperable, so building an experiment is a matter of choosing among them.

CPU only is a supported target rather than a fallback

The features section says GPU is supported but not required, and that CPU only use cases require only a lightweight installation with minimal dependencies. That is a stronger statement than tolerating a fallback, because it commits to a supported configuration.

The requirements line agrees: the library requires Python 3.10 or newer, and for using the GPU, CUDA 10.1 or newer is required. The GPU constraint is placed on CUDA rather than on a specific framework, so it is a property of the machine and not of the extras you chose.

There is a mild tension between that and the extras structure. A user who wants transformers models and runs on CPU gets torch installed anyway, because the transformers extra requires the pytorch extra. So the lightweight CPU path is real but it is the path that does not use transformer models.

The examples follow the same split. There is a binary classification example, a PyTorch multi-class example and a transformer-based multi-class example, and the first of those is the one that runs without the extras.

The published record runs from an EACL demo to a 2026 adoption survey

This is a research library with a citation trail rather than a tool with a changelog. The paper introducing small-text was accepted at EACL 2023 and was then awarded the EACL Best System Demonstration award, and the README calls out both.

The applications listed are drawn from the fields the library is actually used in: bootstrapping a biomedical corpus of digenic variant combinations, detecting disclosures of individuals' employment status on social media, accelerating systematic literature reviews, topic categorisation of citizen contributions, and classifying speech acts in political communication. Each is linked to its own paper rather than described.

The more recent news item runs the other way, from tool to field. A community survey dated 8 March 2026 asks how active learning is used in NLP today, published as an EACL 2026 paper with an arXiv identifier, under the title Reassessing Active Learning Adoption in Contemporary NLP.

That combination, a best demo award for the tool and an adoption survey for the method, is unusual for a library. It means the maintainers are tracking whether the approach is being taken up, not only whether the package still installs.

A DCO, a noxfile and a separate third-party code notice

The top level of the repository is eighteen entries and several of them say how the project is governed rather than what it contains.

There is a DCO.md, so contributions are made under a Developer Certificate of Origin rather than a contributor licence agreement. Alongside it sit CONTRIBUTING.md and CONTRIBUTORS.md, and SECURITY.md for disclosure. LICENSE is referenced from the manifest as a file rather than as a licence expression.

The tooling is split across three configuration files for one project. There is a .flake8 at the root, a pytest.ini, and a pyproject.toml that carries the metadata. There is also a noxfile.py, which means the test sessions are declared as nox sessions rather than only as a pytest invocation.

Then there is a file called THIRDPARTY-CODE as a bare name, alongside MANIFEST.in and a MIGRATION_GUIDE.md. Three requirements files sit at the root level of the dependency story as well, one for development, and one inside the examples directory for the notebooks. The examples themselves are three Python scripts and three notebooks, the third of which uses SetFit rather than the library's own classifiers.

Editorial conclusion

Use this if you have a classification problem with a large unlabelled pool and a small labelled one, and you want evaluated query and stopping strategies rather than a loop you write yourself. Skip it if you need a stable interface contract, because the current build is 2.0.0.dev4 and the README explicitly declines to guarantee one. Before you install, decide whether you need transformer models, since that choice determines whether torch is pulled in, and read MIGRATION_GUIDE.md if you are coming from the 1.x line.

Frequently asked questions

Official sources

1. License: MIT
2. Project website
3. README
4. Releases
5. webis-de/small-text on GitHub