qlib: the published wheel is over a year behind main, and the container installs the wheel rather than your checkout

The newest release is from August 2025 while main was pushed in September 2026

The release record and the commit record are on different clocks. The three recent releases are v0.9.7 dated 2025-08-15, v0.9.6 dated 2024-12-23, and v0.9.5 dated 2024-05-24, while the last push to the default branch is dated 2026-09-22. So more than a year of work sits on main without a tagged release, and the gaps between earlier releases were already long, roughly a year between v0.9.5 and v0.9.6. The version itself is dynamic, taken from the repository state by setuptools-scm, which means a source install reports a version the released wheel never had. The consequence for anyone installing is a choice you have to make on purpose: the published package is over a year behind what you can read in the repository, and a model, a fix, or an example you plan to copy may exist only on main. The tooling is locked down tightly, by the way, down to a private Node package whose only job is checking pull request titles and which demands Node 22.12.0 or newer with its commit linter pinned to an exact version.

The package classifies itself as Alpha and pins the floor at Python 3.8

The build configuration is blunt about its own status. The development status classifier is 3 - Alpha, the required Python is 3.8.0 or newer, and the classifier list runs from 3.8 through 3.12 across Linux, Windows, and macOS. The distribution is named pyqlib, described as a quantitative-research platform, and the version is dynamic rather than written down. An alpha classifier on a research platform is a reasonable signal about API stability, and it matters more here than usual because the example workflows are code rather than configuration, so a signature change breaks a notebook instead of raising a helpful error. The Python range is the other constraint. A floor of 3.8 means your runtime choice is bounded below by an interpreter that is old enough to be awkward in a current base image, and a ceiling of 3.12 means anything newer is outside what the project has declared.

Three dependencies are capped from above, and the reasons are written in the file

The dependency list is annotated rather than bare, and three of the entries are upper bounds with a stated cause. MLflow is held below 3.13 because Qlib's filesystem tracking backend is disabled by default in that release. filelock is held between 3.16.0 and 3.30 because version 3.30 rejects forks while another thread changes lock descriptor ownership. pandas has a floor of 1.1 with comments explaining that the fillna method parameter was deprecated in pandas 2.1.0 and that Qlib adjusted its call in a specific pull request. There is also a conditional pin that applies only on Windows with Python 3.8, holding one solver to an exact version using the wheel verified in a particular pull request. The consequence is that your resolver must respect those ceilings, and if you upgrade past one of them you are not being cautious, you are hitting a documented incompatibility.

A source install compiles two Cython kernels, so pip is not a pure Python path

setup.py is short and it is the reason a compiler shows up. It declares two C++ extensions against the NumPy include directory: one built from the rolling kernel source and one from the expanding kernel source, both under the data library path. The build system requirements in the project configuration name setuptools, setuptools-scm, cython, and numpy 1.24 or newer, which is the toolchain needed to compile them. The consequence is that installing from a checkout is not something a slim container does by accident, and the project's own container image installs build-essential for exactly this reason. The two kernels are also the part that will not degrade quietly: rolling and expanding window operations are compiled C++, so a host without a working toolchain fails at install time rather than falling back to a slower Python path.

The container copies your code and then installs the released package over it

The Dockerfile copies the whole context into the working directory, and then, near the end, branches on a build argument. The argument defaults to yes, and in that branch it runs `python -m pip install pyqlib` straight from the index; in the other branch it runs `python setup.py install` against the copied tree. So the default image carries a checkout of the repository and then shadows it with the published release. The consequence is a testing trap rather than a theoretical one. If you build the image to try the code on main, you are running the wheel, and any difference you were trying to observe has been replaced by the release. You have to set that build argument to the other value, and it is worth doing explicitly every time rather than trusting the default.

The container pins numpy below the version the build system requires

There is a plain contradiction between two files. The build system requires numpy 1.24.0 or newer, and the container installs numpy 1.23.5, along with pandas 1.5.3, importlib-metadata 5.2.0, cloudpickle below 3, and scikit-learn 1.3.2, before adding cython, packaging, tables, matplotlib, statsmodels, pybind11, and cvxpy from the package index. The base is a Miniconda image tagged latest, and the environment is created with Python 3.8, while the project classifiers run up to 3.12. The consequence is that the image describes a specific historical environment rather than a current one, and it disagrees with the declared build requirement. Do not read the container as a supported configuration matrix, and expect to rebuild it if you need a newer interpreter or a newer numpy than the pins allow.

Two entries on the feature table are marked as not yet fully available

The front page is essentially a changelog table, and it ends where the story moves. Two rows are explicitly incomplete: end-to-end learning is marked as coming soon and under review with a link to an open pull request, and the high-frequency trading example is marked as part of the code released rather than fully released. A third honest limit is the footnote that features released before 2021 are not listed, so the table is a partial history by its own admission. Meanwhile the newest capability, automated factor mining and model optimization, is announced as a separate project with its own repository, its own paper, and its own demo videos, described here as something applied to Qlib rather than shipped inside it. The consequence for a reader is that the capability you came for may live in another repository or still be in review, and this page points there rather than pretending otherwise.

Editorial conclusion

Qlib fits a quant researcher who wants a point-in-time data layer, a benchmark harness, and a model zoo under one workflow API, and who is prepared to work from the repository rather than the published wheel. It does not fit a production pipeline that expects a recent release, because the newest tag on the page is from August 2025, and it does not fit a build host without a C++ compiler. Before adopting, decide whether you want the released package or the checkout, and read the dependency ceilings before your resolver picks them for you.

Frequently asked questions

Official sources

1. Official documentation
2. Official README
3. Project repository
4. Release notes