Equinox: two JAX versions excluded by number, three pinned dependency groups and one unpinned, and still classified alpha

The JAX dependency excludes two specific versions by number

The install section says one thing, which is that Python 3.10 or newer is required, and then gives one command.

pip install equinox

The dependency declaration says more, and the extra part is the interesting bit. The JAX floor is a specific minimum version, and then two later releases are excluded by number in the same requirement string. Nothing in the readme, the documentation link, or the repository explains why those two and not others. A requirement written that way is a record of two specific incidents rather than a compatibility policy, which means a resolver will refuse those versions while happily accepting the ones immediately either side of them. For a library whose entire value is being current with JAX, that is the single most consequential line in the package metadata, and it is invisible to anyone who only reads the readme.

The project still declares itself alpha at version zero point thirteen

The package classifiers include a development status of alpha. The version in the same file is zero point thirteen point eight, and the three most recent tags are all in the zero point thirteen line, spaced a few weeks apart through the spring of 2026. So the project has shipped many releases and still tells an index that it is pre-release software. That is not necessarily a contradiction, since alpha status in the packaging vocabulary often means the API may change rather than that the code is unfinished, but it is a signal a consumer should read literally. The citation reinforces the impression of age: it points at a workshop paper from 2021 with a BibTeX entry for it, five years before the current version line.

The commit hook tool has a different name from its configuration file

The development dependency group pins four tools exactly. One of them is a commit hook runner, and the repository root contains a configuration file named for a different, similarly named tool. So the file and the tool that reads it do not share a name, and the pinned version of the installed tool is specific enough to suggest the arrangement is deliberate rather than a leftover. The other three pins are a type checker, a linter and formatter, and a tool that sorts TOML files. The presence of that last one is itself a small signal: a project that sorts its TOML is a project that has been bitten by key ordering at least once. Everything in this group is pinned to an exact version, which is not what most projects do and which makes the toolchain reproducible by construction.

Two dependency groups are pinned exactly and the test group is not pinned at all

There are three dependency groups. The development group has four entries and every one is pinned to an exact version. The documentation group has eleven entries and every one is pinned to an exact version, which is the right call for a group that decides what your API reference looks like. The test group has four entries and not one of them carries a version constraint: the runtime type checker, the JAX binary package, an optimiser library and the test runner are all unpinned. So the exactness that characterises the rest of this project's toolchain stops at the boundary of the tests, which are the one part of the toolchain where a silent version bump is hardest to attribute. The readme does not mention dependency management beyond the single install command.

A module is one PyTree registration and everything after that is core JAX

The readme makes its central claim twice and then explains it in one sentence. Models are defined with familiar syntax borrowed from the most widely used framework in the field, which the example shows as a class with an initializer and a call method, both of which take and return ordinary arrays. Then the explanation arrives: there is no magic behind the scenes, and all the module type does is register the class as a PyTree. From that point the surrounding library already knows how to work with it, which is why the example then decorates an ordinary function with the two transformations the ecosystem provides and gets gradients out of a model it just defined. The readme's own framing is that this is not a framework, and that anything written in it is compatible with anything else in the ecosystem.

The difference from the two frameworks it names is stated as two points

There is a paragraph addressed to people arriving from the two other model libraries, and it is unusually specific. The first difference is capability: it claims a set of advanced features the other two do not have, naming tree manipulation and runtime errors. The second is construction: models here are just trees, so they pass across the boundaries where the ecosystem's transformations are applied, without special handling. That second point is the load-bearing one, because it is the difference you feel when you change how a model is used rather than which features a menu offers. The comparison is short enough to check, and the readme does not go on to argue the point or list a feature table, which is arguably why it is worth reading.

The recommended ecosystem list has eleven entries and five of them are by the same author

The last section maps the surrounding ecosystem in four groups. One group is type annotations, one is deep learning components, one is scientific computing, and one is further reading. Eleven libraries are named in total. Five of them are published by the author of this library, covering type annotations, differential equation solvers, root finding and optimisation, linear solvers, and symbolic to array conversion. That is a reasonable thing for the author of a foundational library to maintain, and it is also a concentration worth naming, because a reader choosing a numerical solver from this list is choosing from a much narrower set than eleven suggests. One entry is explicitly labelled as a non-ecosystem honourable mention, which is the only place the list admits its own bias.

Editorial conclusion

Equinox suits someone already inside JAX who wants model definitions that behave like ordinary PyTrees rather than like objects owned by a framework, because the whole mechanism is a single PyTree registration and everything after that is core JAX. Verify four things first. The JAX dependency names two specific versions as excluded and gives no reason, so check that before an upgrade. The package still classifies itself as alpha at version zero point thirteen, so expect interface churn. The test dependency group is completely unpinned while the other two groups are pinned to exact versions, so a test run is not reproducible in the way the rest of the toolchain is. And the recommended-ecosystem list is half written by the same author, which is normal for a small ecosystem and worth knowing when you weigh a recommendation.

Frequently asked questions

Official sources

1. Issues
2. License: Apache-2.0
3. patrick-kidger/equinox on GitHub
4. README
5. Releases