Holocron: a PyTorch shelf of vision layers, models and optimizers

default_cfg decides how your image gets resized

Every classification model ships a default_cfg dictionary, and the quick tour builds the preprocessing pipeline out of it rather than hardcoding shapes. The visible part of that snippet loads repvgg_a0(pretrained=True).eval(), reads config off model.default_cfg, and passes config[input_shape][1:] into torchvision Resize with InterpolationMode.BILINEAR, then turns the PIL image into a float tensor and normalizes it. Keeping the resize argument tied to the model's own recorded geometry means a checkpoint and its transform cannot drift apart.

from holocron.models.classification import repvgg_a0

# Load your model
model = repvgg_a0(pretrained=True).eval()

# Preprocessing
config = model.default_cfg

Two things about that fence matter before you copy it. The printed snippet stops in the middle of the Normalize call, so the mean and std values it applies are not visible; read them from model.default_cfg in your own script rather than guessing. The fence also never imports torch, even though ConvertImageDtype(torch.float32) needs the module in scope, so it only runs inside a file that already imported torch.

PyPI ships pylocron while the clone path keeps the capital H

The install instructions name two different things, and mixing them up costs you an afternoon. From a release you get the distribution with pip install pylocron. From source you clone the repository and install the directory in editable mode:

git clone https://github.com/frgfm/Holocron.git
pip install -e Holocron/.

Note the capital H in both the clone URL and the trailing path argument. pyproject.toml sides with the release name: the project table declares name = pylocron, version = 0.2.2.dev0, and a description of modules, operations and models for computer vision in PyTorch. So a grep for Holocron across your own requirements files finds nothing, and a dependency check that compares import names to distribution names will flag every holocron import as missing. The build backend is uv_build, pinned to the 0.12 series, which means building a wheel needs uv rather than a bare setuptools toolchain.

uv sync --locked is the install path the Makefile uses

Two targets define the maintainer setup. make venv runs uv venv --python 3.11, and make install runs uv sync --locked --no-dev. The --locked flag is the point: it fails instead of silently re-resolving, so the checked-in lock decides the versions you get. Two lockfiles exist, uv.lock at the repository root and a second one under api/, which tracks as API_LOCK_FILE. Release plumbing follows the same split, with set-version running uv version --frozen --no-build twice, once for the root project and once with --project pointing at the backend directory.

uv venv --python 3.11
uv sync --locked --no-dev

One small wart: PYTHON_REQ_FILE is assigned /tmp/requirements.txt twice in the same file, once near the top and once at the end of the variable block. Harmless, since the values match, but it makes grepping for that path noisier than it needs to be. The target list also includes docs tooling (install-mintlify, start-mintlify), repo setup (init-gh-labels, init-gh-settings), and a help target that harvests the double hash comments with grep, sort and awk.

Container defaults are pinned to a single amd64 platform

Three variables decide where images land and what shape they take: DOCKER_NAMESPACE defaults to ghcr.io with the owner substituted, DOCKER_TAG defaults to latest, and DOCKER_PLATFORM defaults to linux/amd64. All three use the overridable assignment form, so a caller can replace any of them on the make command line. The default is a hard amd64 image, which is a poor fit for an arm workstation unless you override it.

The image is built from BACKEND_DOCKERFILE, which resolves to api/Dockerfile because BACKEND_DIR points at ./api. That directory is a project of its own: it has its own pyproject.toml, its own uv.lock and its own requirements.txt, wired up as API_CONFIG_FILE, API_LOCK_FILE and API_REQ_FILE. The demo gets the same treatment with DEMO_FILE pointing at ./demo/app.py and DEMO_REQ_FILE at ./demo/requirements.txt, which is how a Gradio front end stays out of the library's dependency set.

Layers are grouped by the job they do inside a network

The catalogue is organised by role rather than by paper date. Activations cover HardMish, NLReLU and FReLU. Losses cover Focal Loss, MultiLabelCrossEntropy, MixupLoss, ClassBalancedWrapper, ComplementCrossEntropy, MutualChannelLoss, DiceLoss and PolyLoss. Convolutions add NormConv2d, Add2d, SlimConv2d, PyConv2d and Involution, regularization holds DropBlock, pooling holds BlurPool2d, SPP and ZPool, and attention holds SAM, LambdaLayer and TripletAttention.

Two citation quirks are worth knowing if you follow the links. MixupLoss points at a PDF path while every other entry uses an abstract page. ZPool and TripletAttention point at the same arXiv entry, 2010.03045, so that link cannot tell you which of the two you are looking at. The whole list also lives under a heading literally titled Paper references, so scanning a table of contents for a layers or losses section turns up nothing.

Three reference directories sit beside the package

Training entry points are split by task into references/classification, references/detection and references/segmentation, described as reference scripts for famous public datasets. The models they cover follow the same split. Classification lists Res2Net, Darknet-24, Darknet-19, Darknet-53, CSPDarknet-53, ResNet, ResNeXt, TridentNet, PyConvResNet, ReXNet, SKNet, RepVGG, ConvNeXt and MobileOne, with Res2Net credited as built on Ross Wightman's implementation in pytorch-image-models. Detection lists YOLOv1, YOLOv2 and YOLOv4. Segmentation lists U-Net, UNet++ and UNet3+.

Box regression has its own entry rather than a model: Distance-IoU and Complete-IoU losses sit under the heading for vision related operations. A separate latency script at scripts/eval_latency.py backs the benchmark section, and a minimal Gradio demo lives in demo/app.py with a live copy hosted on Hugging Face Spaces at the frgfm/Holocron space.

Optimizers arrive in pairs, and one wrapper is experimental

The optimizer list pairs each algorithm with a paper link and adds a second category for wrappers. Standalone optimizers are LARS, Lamb, TAdam, AdamP, AdaBelief, Adan and AdEMAMix, plus customized variants including RaLars. Wrappers are Lookahead and Scout, and Scout is the one entry labelled experimental. That label is the only status marker anywhere in the project, so treat it as a signal rather than an oversight.

The dependency ranges behind all of this are tight on purpose: torch is capped below 3.0.0 and torchvision below 1.0.0, huggingface-hub sits in the 1.x range, numpy below 3.0.0, fastprogress below 2.0.0, matplotlib below 4.0.0, and tqdm needs at least 4.1.0. Two extra pins are marked as indirect and carry advisory and upstream issue links, one referencing a GitHub security advisory and one referencing a torchvision issue number.

No release since July 2022, though commits kept landing

Three tags exist on PyPI. v0.2.1 shipped on 2022-07-16 with the note about rebranded project architecture and bug fixes, v0.2.0 on 2022-02-05 with improved performances, API boilerplate and a demo app, and v0.1.3 on 2020-10-27 with task-specific model trainers and new losses and layers. Meanwhile pyproject.toml declares 0.2.2.dev0, so the working tree carries changes that were never released, and the last push on the default branch is dated 2026-10-01.

The practical consequence: pip install pylocron gives you the July 2022 tree, not the current one, so anything you need from the newer commits has to come from a clone. The repository counts 329 stars, 47 forks and 19 open issues, and the project classifier still reads Development Status :: 4 - Beta. Language support is declared for Python 3.11 through 3.14 with requires-python set to >=3.11,<4, even though the Makefile's venv target asks for 3.11 explicitly.

Editorial conclusion

Holocron fits teams that want one specific block, loss or optimizer dropped into a training loop they already own, and it is better installed from git than from PyPI, since the last tagged release dates from July 2022 while commits kept landing afterwards. Before adopting it, check that your torch version falls inside the declared range and read the source of any module you plan to vendor, because the README is an index of paper links rather than a usage guide.

Frequently asked questions

Official sources

1. frgfm/holocron on GitHub
2. License: Apache-2.0
3. Project website
4. README
5. Releases