nnue-pytorch has no torch in its requirements, and no packaging metadata either

Torch appears in no dependency file, only in the conda recipe

The single requirements file lists fourteen packages and the framework itself is not among them. What is there instead is a supporting cast: process inspection, a terminal toolkit, GPU monitoring, an exactly pinned chess library, plotting, tensorboard, two numeric accelerators, an HTTP client, a CLI argument library, the linter, the test runner, a schedule-free optimizer package, metrics, progress and a scientific stack. Torch is installed by the environment recipe instead, where the create command pulls PyTorch from the project's own channel alongside torchvision and torchaudio. That means the file named requirements is not sufficient on its own, and a reader who installs it into a fresh interpreter gets fourteen imports that mostly fail on the missing framework. There is no separate file for development tooling either, so the linter and the test runner are runtime requirements in the same flat list.

The self-play matcher needs four binaries the setup never installs

Finding the best network means playing thousands of games, and that step is driven by a script with a long command line:

python run_games.py --concurrency 16 --stockfish_exe ./stockfish.master --c_chess_exe ./c-chess-cli --ordo_exe ./ordo --book_file_name ./noob_3moves.epd run96

Four paths appear in that one line and not one of them is in this repository or produced by any setup section. It expects a Stockfish build, a command line chess engine, a ranking tool, and an opening book, all sitting in the working directory. What the script does is described clearly: it finds every checkpoint under the named output directory, converts them to network files, plays games and ranks the results, then loops and watches the directory for new checkpoints, so it is meant to run alongside training on spare cores. None of the README's setup paths, container or conda, mentions acquiring any of those four.

Two of the page's own sections are marked for moving out

The logging section and the self-play section both carry the same short note that they should move to the wiki, and the logging one adds a second note about setting up the easier training script. That is the author telling you these sections are placeholders. The consequence is larger than it first looks, because the two sections marked for removal are precisely the two operational ones: how to watch training progress and how to decide which checkpoint is best. What remains after they go is environment setup. The documentation for training itself is already elsewhere, with two wiki pages given a hard way and an easier way. So a newcomer gets a well-written install guide and has to leave the repository entirely to learn what they installed it for.

The easier training script is documented but absent from the root listing

The training section offers two routes and points each at a wiki page. One is built around the main training script and is labelled the hard way. The other is built around a script whose name suggests it does the orchestration for you and is labelled the easier way, and the logging section separately carries a note about adding setup for it. The repository root listing contains the main training script, and also a distributed launcher, a serialiser, a permissions module, a cross-check evaluation script, a sigmoid fitting script, plotting helpers and several standalone utilities, but no script by the easier name. Either it lives below the root, in a subdirectory the listing does not reach, or the note is stale. Either way, the entry point the documentation recommends to newcomers is the one you cannot see from the root.

Four of fourteen dependencies carry a version constraint

The requirements file mixes four different levels of care. One library is pinned to an exact patch version, the chess library. One linter is pinned exactly. One metrics package has a floor. One has a ceiling only and no floor, the numeric array library, capped below the second major version with nothing underneath. The remaining ten have no constraint at all, including the optimizer package, the HTTP client, the argument parser and both numeric accelerators. A ceiling without a floor is the awkward one, because it tells you what will break but not what you are meant to run, and it will block any future dependency that needs the newer major. There is no lock file at the root and no build metadata, so the only reproducible thing in this repository is that one exact pin.

The container pins two accelerator stacks and asks for tens of gigabytes

The container approach exists so you do not have to build a local Python environment or compile anything, and it ships a specific pair of stacks: one CUDA major line and one ROCm point release, with all dependencies inside. The documentation is explicit that your local toolkit version is then irrelevant, which is the right call, and it links driver requirements to a versioned release-notes page for the container rather than to a moving target. The cost is stated in one parenthetical and it is not small, roughly thirty to sixty gigabytes of disk and an unspecified amount of time to build. Vendor support is split three ways: ROCm needs a current driver, the container toolkit needs the NVIDIA driver plus the NVIDIA container toolkit, and Apple silicon gets no hardware acceleration through Docker at all and is pointed at the conda path instead.

The Apple recipe installs two vision and audio libraries nothing uses

The conda environment for Apple silicon is a readable recipe and it is longer than it needs to be. It pins Python 3.12, pulls PyTorch, and then adds torchvision, torchaudio, a compiler collection, an LLVM OpenMP runtime, cmake and make. For a project that trains a scalar evaluation function from chess positions, the vision and audio packages have no role that the page explains. It also installs both a generic JPEG library and a turbocharged JPEG implementation, which are competing implementations of the same interface rather than complementary pieces. The sequence that follows is the right shape: install the requirements without a cache, then run the setup script. That setup script is where the native compilation happens, which is the step the Docker route was chosen to avoid.

A Python repository carrying clang-format and a profiling directory

The root tells you more about the project's shape than the README does. There is a C++ format configuration and a companion ignore file for it, both at the top level of a Python repository. There is a profile-guided optimisation directory, committed, which only makes sense if native code is compiled with instrumentation. And there is no packaging metadata at all: no project file, no setup script for pip, no separate development requirements. Eleven executable scripts sit flat at the root alongside four real packages, so importing this project means putting its root on your path rather than installing it. One of those root scripts carries a name that appears nowhere in the documentation, a permissions module whose purpose has to be inferred from the filename, and another fits a sigmoid against performance data, which is tooling well outside a plain training script.

Editorial conclusion

Use this if you intend to actually train an evaluation network rather than consume one, since it is the reference implementation with the sparse data loader, the checkpoint serialiser and the self-play matcher that production Stockfish nets are built with. Plan for the unglamorous parts. The container build is tens of gigabytes, Apple silicon cannot use it for hardware acceleration, torch is not a declared dependency anywhere, and the match evaluator expects three external binaries and an opening book that the setup sections never mention. And read the wiki before anything else, because the repository deliberately does not contain the training procedure and two of its own sections are flagged as unfinished.

Frequently asked questions

Official sources

1. Issues
2. License: GPL-3.0
3. official-stockfish/nnue-pytorch on GitHub
4. README